Collections and strong mode

[donny-dont]

From collections, https://www.dartlang.org/effective-dart/usage/#collections, it says.

You can even provide a type argument for them if that matters.

var points = <Point>[];
var addresses = <String, Address>{};

You might want to mention something about strong mode wanting the additional type information.

[sethladd]

cc @vsmenon @leafpetersen how bad does strong mode want generics on collections?

[vsmenon]

In general, the more precise the type, the more benefit you'll get from strong mode. At the moment, it's not required.

That said, we will think about tightening this. We have at least a couple requests to warn (e.g., dart-lang/sdk#24712) about implicit dynamics of this form.

[leafpetersen]

There seem to be some different modes of use of strong mode developing, so we're still considering exactly how to surface this and what options to offer users to control this. Here's the current status though.

If you use the collection literal/constructor in a fully typed context (assign it to a variable with an instantiated type, pass it to a function with a fully instantiated type) we will infer the type and not complain.

List<int> x = [3]; // no complaints
((List<int> x) => x.length)([3]); // no complaints

If you leave the type argument off in an untyped context, we will use dynamic for the argument. We will not complain directly, but if you try to use the result at an instantiated type we will complain.

  var x = [3]; // no complaints, x has type List<dynamic>
  List<int> y = x; // we emit a warning

This is just a warning, but code like this will fail in the dev compiler, and so should be avoided in code that is intended for the web.

As @vsmenon says, some groups would like to get feedback from strong mode to allow them to squash any such implicitly typed objects, since they can be dangerous. We will likely support this.

dart-lang/sdk#24712
dart-archive/dev_compiler#363
dart-archive/dev_compiler#365

[munificent]

Strong mode is a bit of a moving target, so I don't want to mention it in the guidelines just yet. Once we have a clearer picture of what the best practices are, I'm fine with revising the guides. But, for now, I think it's good to be a little vague.