--no-implicit-dynamic should take @optionalTypeArgs into account

[zoechi]

@optionalTypeArgs
class MapDataItem<K, V> extends DelegatingMap<K, V> implements DataItem<K, V> { ... }

[kevmoo]

FYI @jmesserly

[jmesserly]

what is @optionalTypeArgs ...?

[zoechi]

https://pub.dartlang.org/packages/meta

[jmesserly]

Hmmm. But what's it used for? I don't understand why it's a good idea. It seems to defeat the purpose of --no-implicit-dynamic, which is opt in, but is intended to give you confidence there is no "accidental dynamic" in your code anywhere.

There is a way to get similar behavior with strong mode+no-implicit-dynamic:

class MapDataItem<K extends Object, V extends Object> extends ...

By adding extends Object it changes the default behavior, now it will implicitly instantiate with Object, which unlike dynamic, is a somewhat safe default. At least, much safer and seems more in the spirit of "no-implicit-dynamic".

I suppose we could combine them and have @optionalTypeArgs mean implicit Object. Or we just make implicit Object always. The problem is, it doesn't help if you plan on downcasting:

f(MapDataItem<String, int> m) { ... }

var myItem = new MapDataItem(...);
f(myItem); // boom, cast failure!

That's why we were trying to encourage type arguments. With a type like MapDataItem<K, V> we should pretty much always infer from the constructor key/value type anyway (ctors have upwards+downwards inference now).

CC @leafpetersen as well

[zoechi]

I didn't realize that generic type parameter constraints are used this way. I tried it and it seems to solve my problem.

I like this better than @optionalTypeArgs which I used for exceptions to always_specify_types

[zoechi]

BTW 🍻 🍻 🍻 for --no-implicit-dynamic. I was missing this since I started using Dart.

[jmesserly]

awesome! Let us know if that feeling changes based on experience :) I will leave this open because it's at least an inconsistency we should think about. And I do worry about taking away the nice "raw type" syntax. If it seems to come up a lot, we can bump the priority to figure out something better.

[jmesserly]

Closing this issue as stale; we do have work planned for new --strict flags in Analyzer that should be easier to use compared to --no-implicit-dynamic