Adjusted spec of initializing formal type annotation

During migration of lib/mirrors/initializing_formals_test.dart to lib_2
it became apparent that strong mode makes it an error to have different
type annotations on an initializing formal and the corresponding field.
The language team discussed this and decided that we will take a middle
way: These type annotations can differ, but the initializing formal
must have a subtype.

This CL adjusts the spec to say that. In line with the rest of the
spec it is still a static warning (we will migrate all the static
warnings to errors as a separate step).

Change-Id: I66656c2933b7f86b78f0b06eadbf5edc0f58a3c6
Reviewed-on: https://dart-review.googlesource.com/7264
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
This commit is contained in:
Erik Ernst 2017-09-20 11:38:26 +00:00 committed by commit-bot@chromium.org
parent 83de2423ae
commit 8562c8ff1b

View file

@ -29,6 +29,7 @@
% namedArguments on Invocation.
% - Remove the, now unnecessary, handling of invalid overrides of noSuchMethod.
% - Add >>> as overridable operator.
% - If initializing formal has type annotation, require subtype of field.
%
% 1.15
% - Change how language specification describes control flow.
@ -1348,7 +1349,7 @@ A {\em constructor parameter list} is a parenthesized, comma-separated list of f
\LMHash{}
If an explicit type is attached to the initializing formal, that is its static type.
Otherwise, the type of an initializing formal named $id$ is $T_{id}$, where $T_{id}$ is the type of the instance variable named $id$ in the immediately enclosing class.
It is a static warning if the static type of $id$ is not assignable to $T_{id}$.
It is a static warning if the static type of $id$ is not a subtype of $T_{id}$.
\LMHash{}
Initializing formals constitute an exception to the rule that every formal parameter introduces a local variable into the formal parameter scope (\ref{formalParameters}).