Consider `avoid_dynamic_calls` as a lint rule.

[srawlins]

I think avoid_dynamic_calls would be a great addition to the lint rule sets. Either in core or in recommended.

https://dart-lang.github.io/linter/lints/avoid_dynamic_calls.html

It is currently marked experimental. See dart-lang/sdk#58409

[mit-mit]

Not approved: dynamic is fully supported in the language, and something a developer is free to use if they desire.

[yjbanov]

@mit-mit How does a lint prevent a developer from using dynamic calls if they desire? 🤔 My understanding is that the lint would be used (optionally) by developers who do not desire to have dynamic calls in their codebase, or at least, in rare situations where they do need one, they want it flagged and worked around using an // ignore: avoid_dynamic_calls.

I was looking forward to this lint to use in the Flutter Web engine. We don't need dynamic invocations in the engine, but our codebase is big, so we don't know if we have some dynamic calls that sneaked in by accident, potentially hurting performance and/or code size.

Also, my understanding is that the lint doesn't lint against dynamic. It only lints against dynamic invocations. For example, the following code is totally legal:

dynamic json = parseJson(jsonString);
if (json is Map) {
  dynamic someField = json['some_field'];
  if (someField is num) {
    print(someField.toStringAsFixed(2));
  } else if (someField is String) {
    print(someField);
  } else {
  // ... etc ...
}

What would be flagged is this:

dynamic json = parseJson(jsonString);
json['some_field'].toStringAsFixed(3);
//  ^              ^
//  |              | dynamic invocation of toStringAsFixed
//  dynamic invocation of operator[]

Those invocations can crash, and they can cause retention of methods on unrelated classes. In codebases, such as the Flutter Engine, flagging such situations would be super useful.

(Edit: minor fixes; clarification; examples)

[mit-mit]

This issue doesn't track the availability of this lint; it tracks whether the lint is enable by default in package:lints / package:flutter_lints. Thus the triage decision is wrt. what we decide to enforce out of the box, not what you can individually configure in your analysis_options.yaml file. Does that explain our triage decision?

[mit-mit]

Oh, but maybe the confusion is that @srawlins logged this as a request to have this as a supported lint? Then we can certainly reactivate and transfer to https://github.com/dart-lang/linter/issues...

[srawlins]

The rule exists. This was a request to add the rule to the lints:core or lints:recommended rule set.

[yjbanov]

Ah, cool. If this can be optionally added to analysis options, I have no further concerns.

[goderbauer]

I hear there were some recent discussion around dynamic in the dart language team and the notes of that discussion made me wonder whether it would actually be a good thing to push people towards avoiding dynamic calls by adding this lint to "recommended" after all.

/cc @munificent @eernstg you were part of these discussions. Curious to hear what you think.

[eernstg]

I guess it is possible to disable a recommended lint in a package and certainly using // ignore_for_file:.... That might make it a good trade-off to enable this lint for anyone who doesn't actively turn it off. After all, a dynamic invocation which is not seen as such can be rather misleading when it comes to potential run-time errors.

[goderbauer]

@mit-mit Can you reopen this issue for reconsideration during our next lint triage?

[goderbauer]

It came up in a recent discussion that a surprisingly high number of the top 200 runtime errors reported by our flutter analytics are related to dynamic. There is some hope that enforcing a lint like this (and/or #800 could help in reducing that number).

[devoncarew]

I guess it is possible to disable a recommended lint in a package and certainly using

From a discussion, I believe another way that was proposed to disable this lint was via an explicit cast; so:

(value as dynamic).fooBar();

cc @leafpetersen