Allow type instantiation as expression.

[lrhn]

Dart does not allow you to write List<int> as an expression evaluating to a Type object, instantiating the generic class. This is inconvenient to users, who have to resort to helper functions like Type typeOf<T>() => T;.

Dart does not allow you to write genericFunction<int> to create a specific type instantiation of a generic function, but it does allow T id<T>(T x) =>x; int Function(int) intId = id; to implicitly instantiate the generic function. It should be possible to write the type explicitly.

Dart does not allow constructor tear-offs - the syntax Foo<int> or Foo<int>.named are not valid expressions. if Foo<int> was allowed syntax, then this would be an easy extension.

So, as a feature, Dart should allow type instantiation of all generic elements (typedefs, classes and functions) and allow constructor tear-offs.
The syntax List<int> can be seen both as a type and as the name of the unnamed constructor. I propose using the context type to distinguish: If the context type is Function or any function type, the expression is considered a tear-off of the unnamed constructor, otherwise it is a Type object.

This looks like two features, but because of the syntactic overlap, they should be implemented at the same time.

And if expression < type* > is valid expression syntax, we can also do explicit instantiation of generic method tear-offs.

(If we extend type literal syntax to allow List<int>, then we might also want to allow int? as a NNBD type literal).

[eernstg]

We have discussed this feature earlier, along with some grammar ambiguities. I believe that we could avoid those syntactic difficulties by putting this construct near expression in the set of grammar rules. This means that there are a number of locations where it cannot occur (because they require an assignableExpression or a postfixExpression or some other more specific thing), but in all those cases we would be able to use parentheses to make it a primary, which is allowed "everywhere". For instance, we wouldn't be able to do List<int>.toString(), but we could do (List<int>).toString(). This should be helpful in order to disambiguate named contructor invocations from other expressions (because we should still be able to create a list using List<int>.filled(10,0)).

[leafpetersen]

We could also consider generic getters as part of this. Unfortunately, I haven't found any good syntax for generic setters. x =<T> e could work, but sure is ugly.

[munificent]

If the context type is Function or any function type, the expression is considered a tear-off of the unnamed constructor, otherwise it is a Type object.

I think constructor tear-offs are more useful than Type objects, so I wish we could make those the default. Otherwise, things like this don't work (do they?):

(removeDuplicates ? List.from : Set.from)(elements)

Otherwise, this SGTM.

We could also consider generic getters as part of this.

You know, I feel like I should want this in principle because it generalizes, but I can't say I've ever actually found myself wanting it in practice.

Unfortunately, I haven't found any good syntax for generic setters. x = e could work, but sure is ugly.

Eek, yeah. Does this not work:

object.setter<T> = value;
setter<T> = value;

?

[natebosch]

I think constructor tear-offs are more useful than Type objects, so I wish we could make those the default.

It would be breaking to make var l = List tear off the constructor instead of being a type.

Since var l = List.from; or var l = List<int>.from; already are errors I think it would not be breaking if we use new as the "magic" name for the unnamed constructor: var l = List.new.

[leafpetersen]

This should cover nullable types as well: e.g int? as a literal.

[lrhn]

Allowing int? as an expression might get us into parsing ambiguities, fx. int?[42] can be both (int?)[42] and (int)?[42].
It's most likely never going to be an issue for bug-free code, but we'll have to disambiguate in some way and it might make some error recovery harder.

[eernstg]

Note that a very old SDK issue, dart-lang/sdk#11923, was used to discuss this topic as well. I closed dart-lang/sdk#11923 as a duplicate of this one, because this one is directly phrased as a language feature proposal and has the more recent discussion.