Adjusted the spec to include access to initializing formals.

docs/language/dartLangSpec.tex

 \documentclass{article}
 \usepackage{epsfig}
 \usepackage{color}
 \usepackage{dart}
 \usepackage{bnf}
 \usepackage{hyperref}
 \usepackage{lmodern}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification  \\
 {4th edition draft}\\
@@ skipping 1209 matching lines @@
     .
  \end{grammar}
 
 \LMHash{}
 A {\em constructor parameter list} is a parenthesized, comma-separated list of formal constructor parameters. A {\em formal constructor parameter} is either a formal parameter (\ref{formalParameters}) or an initializing formal. An {\em initializing formal} has the form \code{\THIS{}.id}, where \code{id} is the name of an instance variable of the immediately enclosing class.  It is a compile-time error if \code{id} is not an instance variable of the immediately enclosing class. It is a compile-time error if an initializing formal is used by a function other than a non-redirecting generative constructor.
 
 \LMHash{}
 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.
+Initializing formals constitute an exception to the rule that every formal parameter introduces a local variable into the formal parameter scope (\ref{formalParameters}). 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 in the formal parameter list introduces a local variable into the formal parameter initializer scope, but not into the formal parameter scope; every other formal parameter introduces a local variable into both the formal parameter scope and the formal parameter initializer scope.

[Lasse Reichstein Nielsen, 2016/08/23 06:55:20]

Consider splitting this into more lines.
I believe TeX isn't picky about that.

Comma after "formals" in "any initializing formals, a new scope"

Are we absolutely sure this is unambiguous, and can't be read in such a way that
the variables introduced into both scopes by normal formal parameters are
different variables (have separate storage)?

(I admit that the existing description isn't exactly precise about bindings)

[Lasse Reichstein Nielsen, 2016/08/23 07:15:03]

I can't see anything saying that the initializing-formal formal variable is
final.

[eernst, 2016/08/23 16:26:30]

I believe that this has now been covered by adding the word final.

[eernst, 2016/08/23 16:26:30]

TeX/LaTeX is perfectly happy (it takes two consecutive line breaks
to start a new paragraph), but the current style in the spec uses
a single line for an overwhelming majority of the paragraphs. The
typical exception is where there is a paragraph and the paragraph
ends in `\begin{itemize}..\end{itemize}`. In that case the whole
itemize block is given separate lines.

So I was just trying to avoid messing up the style too much. We could
start using lots of line breaks. I'm quite happy with a format where
each line is up to 80 chars and M-q in emacs is used to "fill" the
paragraph now and then, but this tends to make diffs harder to read.

One intermediate form would be where we tend to put each sentence on
a new line (so period forces a line break). This would probably give
us more readable diffs while still avoiding the hugely long lines.

Just for taking a look at it, I used that style now, in text that is 
affected by this CL.
Done.
The spec already mentions that variables "are" storage locations. The current
wording implies that it is one variable which is added to two
scopes, so you could say that it is already disambiguated. Because of
this, I just added a sentence to the commentary in order to make it 
explicit that it is one variable and one storage location.
Right, but I believe we should be OK in that respect now.

+
+\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. The type of the constructor is defined in terms of its formal parameters, including the initializing formals.

[Lasse Reichstein Nielsen, 2016/08/23 06:55:20]

commas around "including initializing formals".
"in scope for initializers" -> "in scope for the initializer list"
(I don't think we use "initializers" alone as a noun).

[eernst, 2016/08/23 16:26:30]

Done.
Done.

+}
 
 \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.
 
 
 \commentary{
 The above rule allows initializing formals to be used as optional parameters:
 }
 
 \begin{dartCode}
@@ skipping 6648 matching lines @@
 
 The invariant that each normative paragraph is associated with a line
 containing the text \LMHash{} should be maintained.  Extra occurrences
 of \LMHash{} can be added if needed, e.g., in order to make
 individual \item{}s in itemized lists addressable.  Each \LM.. command
 must occur on a separate line.  \LMHash{} must occur immediately
 before the associated paragraph, and \LMLabel must occur immediately
 after the associated \section{}, \subsection{} etc.
 
 ----------------------------------------------------------------------