Adjusted spec to outlaw built-in identifiers in type annotations.

Addresses issue https://github.com/dart-lang/sdk/issues/28817.

R=lrn@google.com

Review-Url: https://codereview.chromium.org/2704573004 .
This commit is contained in:
Erik Ernst 2017-02-20 09:27:37 +01:00
parent 7f83d9d173
commit 5de9108c16

View file

@ -5402,7 +5402,9 @@ An {\em identifier expression} consists of a single identifier; it provides acce
\end{grammar}
\LMHash{}
A built-in identifier is one of the identifiers produced by the production {\em BUILT\_IN\_IDENTIFIER}. It is a compile-time error if a built-in identifier is used as the declared name of a prefix, class, type parameter or type alias. It is a compile-time error to use a built-in identifier other than \DYNAMIC{} as a type annotation or type parameter.
A built-in identifier is one of the identifiers produced by the production {\em BUILT\_IN\_IDENTIFIER}.
It is a compile-time error if a built-in identifier is used as the declared name of a prefix, class, type parameter or type alias.
It is a compile-time error to use a built-in identifier other than \DYNAMIC{} in a type annotation or type parameter.
\rationale{
Built-in identifiers are identifiers that are used as keywords in Dart, but are not reserved words in Javascript. To minimize incompatibilities when porting Javascript code to Dart, we do not make these into reserved words. A built-in identifier may not be used to name a class or type. In other words, they are treated as reserved words when used as types. This eliminates many confusing situations without causing compatibility problems. After all, a Javascript program has no type declarations or annotations so no clash can occur. Furthermore, types should begin with an uppercase letter (see the appendix) and so no clash should occur in any Dart user program anyway.