allow generic type constants

[trinarytree]

to reproduce

---

print(List); // works
print(List<int>); // parse error. boo!
print(<int>[].runtimeType) // works, but ugly: had to create an instance.

this makes dependency injection ugly (using angular/di.dart):
abstract class Producer<T> {
  T get();
}
bind(Producer, toValue: prometheus); // works, but useless: Producer is too general
var dataProducer = new DataProducerImpl();
bind(Producer<Data>, toValue: dataProducer); // parse error :-(
bind(dataProducer.runtimeType, toValue: dataProducer); // ugly, and doesn't work anyway due to bug in di
bind(new TypeLiteral<Producer<Data>>().type, toValue: new DataProducerImpl()); // works, but even uglier and hard to discover this feature

expected

---

if List can be used as an object, seems like List<int> should be allowed too.
then it would be possible to implement di so that
bind(Producer<Data>, toValue: dataProducer) works as expected.

this might be related to bug 12921, but the conversation there is all over the place,
so i honestly can't tell.

Dart VM version: 1.10.0-dev.0.2 (Thu Apr 2 20:17:30 2015) on "linux_x64"

[lrhn]

The common work-around is to have a class:
 class TypeOf<T> {
   Type get type => T;
 }
so you can write new TypeOf<List<int>>().type instead of using runtimeType.

The grammar could be unambiguous.
 t<a>
is not a valid expression no matter what follows, and
 t<a, b>
is only a problem if an expression follows immediately after the '>' because
 foo(t < a, b > c)
would be a function taking to comparison-results as arguments. Without the "c", there is no other valid interpretation, so Map<int,int> would not have an existing meaning.

The biggest problem is that the parser needs arbitrary lookahead to know how to parse
  foo(t<a, b, c, d, e, f, g, h, ...., z> /* expression or no expression here */)

 

---

Added Area-Language, Triaged labels.

[trinarytree]

interesting. (btw i assume that you meant "the grammar could be ambiguous".)
doesn't the parser already have this problem?:
bar(foo) {
  foo(t<p1, ..., pn> x) { /* case I: locally declared function / }
  foo(t<p1, ..., pn > x); / case II: call foo with arguments (t<p1), p2, p3, ..., (pn > x) */
}
either the parser can or it cannot distinguish between the 2 cases above before reaching the symbol after the ).
if it cannot, then this isn't a valid objection to allowing t<a> as an expression.
if it can, then it seems like it still can distinguish even if we allow t<a> as an expression.

i have a feeling that what really happens is that it can, and it can because t is a type literal,
which cannot be compared with the < operator. i.e. case II can't really happen.
similarly, in the objection at the end of post #­1, foo(t<a, ..., z>, we know immediately that the <
should be interpreted as introducing a generic param because t is a type literal;
well, we know it as long as we know that t is a type literal, but if we don't know that, then my example above
shows that we can't distinguish between cases I and II even today until we get to after the ).

[kevmoo]

Added Duplicate label.
Marked as being merged into #11923.