Attempting to use a type with type arguments as a constant produces too many diagnostics

[scheglov]

main() {
  const v = List<int>;
}

Results in the following errors when I run:

bin/test.dart:2:21: Error: An equality expression can't be an operand of another equality expression.
Try re-writing the expression.
  const v = List<int>;
                    ^
bin/test.dart:2:22: Error: Expected an identifier, but got ';'.
  const v = List<int>;
                     ^
bin/test.dart:2:17: Error: The method '<' isn't defined for the class 'Type'.
 - 'Type' is from 'dart:core'.
Try correcting the name to the name of an existing method, or defining a method named '<'.
  const v = List<int>;
                ^

However I'd expect this to work, because 16.2 Constants says that type arguments are allowed:

@danrubel

[scheglov]

Ah, actually this is wrong.
constant type expression is not a constant expression, it jus can be used (in the future) in as and is.

[bwilkerson]

What makes you think so? The current version of the spec reads:

A simple or qualified identifier denoting a class, a mixin or a type alias that is not qualified by a deferred prefix, is a potentially constant and constant expression.

The constant expression always evaluates to a Type object. For example, if C is the name of a class or type alias, the expression C is a constant, and if C is imported with a prefix p, p.C is a constant Type instance representing the type of C unless p is a deferred prefix.

But even if it isn't a valid constant expression, I think we need to improve recovery in this case.

[scheglov]

An identifier - yes, but it does not say anything about type arguments.

Recovery could be better, that's true.

[bwilkerson]

@eernstg Is the disallowing of type arguments intentional?

[eernstg]

@scheglov, I believe the rules match your comment here quite well:

A constant type expression is required where a type is used as such in a constant expression, e.g., as a type argument in a list/set/map literal or a <constObjectExpression>. A <qualified> term that denotes a type declaration may be a constant type expression and also a constant expression, and it's the latter that makes const v = MyClass; valid.

But we don't have the ability to use expressions ending in <typeArguments> anywhere, so they certainly can't be correct as constant expressions either.

@bwilkerson, I don't think anyone has been pushing for an error with these expressions, it's the other way around: We discussed adding support for terms like List<int> as an expression, for obtaining a reified type, and terms like foo<int> and myReceiver.bar<int> as expressions, for requesting generic function/method instantiation with explicit type arguments. So it's not surprising that the situation is as described, we just haven't done it yet.

[bwilkerson]

I've updated the title to reflect the real issue.

@danrubel