Adjusted the spec to include access to initializing formals.

docs/language/dartLangSpec.tex

Index: docs/language/dartLangSpec.tex
diff --git a/docs/language/dartLangSpec.tex b/docs/language/dartLangSpec.tex
index 0b76367151cb8dc4d241284cec129433f7401bc4..d4adf323cbbb140cdf84c3311bac9cd707735509 100644
--- a/docs/language/dartLangSpec.tex
+++ b/docs/language/dartLangSpec.tex
@@ -1227,7 +1227,14 @@ A {\em constructor parameter list} is a parenthesized, comma-separated list of f
 If an explicit type is attached to the initializing formal, that is its static type. Otherwise, the type of an initializing formal named \code{id} is $T_{id}$, where $T_{id}$ is the type of the field named \code{id} in the immediately enclosing class. It is a static warning if the static type of \code{id} is not assignable to $T_{id}$.
 
 \LMHash{}
-Using an initializing formal \code{\THIS{}.id} in a formal parameter list does not introduce a formal parameter name into the scope of the constructor. However, the initializing formal does effect the type of the constructor function exactly as if a formal parameter  named \code{id}  of the same type were introduced in the same position.
+When the formal parameter list of a non-redirecting generative constructor contains any initializing formals a new scope is introduced, the {\em formal parameter initializer scope}, which is the current scope of the initializer list of the constructor, and which is enclosed in the scope where the constructor is declared. Each initializing formal \code{\THIS{}.id} in the formal parameter list introduces a formal parameter name into the formal parameter initializer scope, but not into the formal parameter scope.

[Lasse Reichstein Nielsen, 2016/08/08 08:22:06]

This does not specify what that name will be bound to in the new scope.
This is a synthetic parameter, so it doesn't correspond to an actual argument
(well, it could, but I guess it won't).
That means that it's not clear what the scope binds the name to - is it a
variable or a value or something else?

The spec says that a scope induces a namespace that maps a name to a variable,
type or function declaration, so in this case I guess it should map to a
synthetic final variable.

[eernst, 2016/08/08 15:40:57]

I think the binding is already specified in the specification: Section 9.2 has
'Every formal parameter introduces a local variable into the formal parameter
scope'.

So is it true that an initializing formal is a formal parameter? We have (9.2.1)
that 'A required formal parameter may be specified in one of three ways', one of
which is an initializing formal. The use of `fieldFormalParameter` in required +
optional positional + named parameters makes it clear that all three work the
same: _Every_ initializing formal is a formal parameter. So they 'introduce a
local variable into the formal parameter scope.'

This location is then adding an exception to this rule, both in the old and the
new wording.

However, they both have a problem: We need to specify _explicitly_ that this
paragraph is an exception to the rule in section 9.2. We also need to clarify
that the formal parameter initializer scope gets all formals, not just the
initializing ones.

Adjusted the paragraph to fix those issues. This also brought the terminology
more in line with 9.2 (explicitly mentioning the local variable).

+
+\commentary{
+This means that formal parameters including initializing formals must have distinct names, and that initializing formals are in scope for initializers, but they are not in scope for the body of the constructor.

[Lasse Reichstein Nielsen, 2016/08/08 08:22:06]

I don't see how this can be concluded from the previous section.
The spec allows nested scopes to contain the same name, so you have to
explicitly write that code is not allowed to use the same name for an
initializing formal and a non-initializing formal parameter.

[eernst, 2016/08/08 15:40:57]

I think this problem has been resolved with the change I made to the previous
paragraph: It explicitly says that all formals are added to the formal parameter
initializer scope (and the general rule about name clashes hence applies for
them all).

There is no need to consider conflicts among nested scopes, because the formal
parameter initializer scope and the formal parameter scope are siblings (same
parent), not nested, and that hasn't been changed.

+}
+
+\LMHash{}
+The type of the constructor function is derived from the formal parameter initializer scope such that it takes all parameters into account, including initializing formals.

[Lasse Reichstein Nielsen, 2016/08/08 08:22:06]

Is this necessary? (That is: Was the type of a constructor undefined before?)

I think the type of the function should be derived from it's *declaration*, not
the scopes it contains internally. For one thing, scopes are not ordered, so you
can't derive the correct type for positional parameters from a scope.

[eernst, 2016/08/08 15:40:57]

I think you are right: We can omit this. Sect. 9.3 specifies the type of a
function based on its formal parameters, and we have just checked that
initializing formals are formal parameters. That makes this sentence redundant
already before the CL (so we don't need to discuss whether the pre-CL and the
post-CL wordings are equivalent).

Changed it into a part of the commentary above.

 
 \LMHash{}
 Initializing formals are executed during the execution of generative constructors detailed below. Executing an initializing formal  \code{\THIS{}.id} causes the field \code{id} of the immediately surrounding class to be assigned the value of the corresponding actual parameter, unless $id$ is a final variable that has already been initialized, in which case a runtime error occurs.