Various fixes to wording and typos.

docs/language/dartLangSpec.tex

Index: docs/language/dartLangSpec.tex
diff --git a/docs/language/dartLangSpec.tex b/docs/language/dartLangSpec.tex
index 886d65b307988edc17c706e45c3940259f2ecbc2..140a8df4fafc328bc0b4fd246f9ad83805d0d7b9 100644
--- a/docs/language/dartLangSpec.tex
+++ b/docs/language/dartLangSpec.tex
@@ -7,8 +7,8 @@
 \usepackage{lmodern}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification  \\
-(4th edition draft)\\
-{\large Version 1.11}}
+{4th edition draft}\\
+{\large Version 1.14}}
 
 % For information about Location Markers (and in particular the
 % commands \LMHash and \LMLabel), see the long comment at the
@@ -35,7 +35,7 @@ This Ecma standard specifies the syntax and semantics of the Dart programming la
 \LMLabel{ecmaConformance}
 
 \LMHash{}
-A conforming  implementation of the Dart programming language must provide and support all the  APIs (libraries, types, functions, getters, setters, whether top-level, static, instance or local) mandated in this specification. 
+A conforming  implementation of the Dart programming language must provide and support all the  APIs (libraries, types, functions, getters, setters, whether top-level, static, instance or local) mandated in this specification.
 
 \LMHash{}
 A conforming implementation is permitted to provide additional APIs, but not additional syntax, except for experimental features in support of null-aware cascades and tear-offs that are likely to be introduced in the next revision of this specification.
@@ -61,7 +61,7 @@ Dart API Reference, https://api.dartlang.org/
 Terms and definitions used in this specification are given in the body of the specification proper. Such terms are highlighted in italics when they are introduced, e.g., `we use the term {\em verbosity} to refer to the property of excess verbiage'.
 % End Ecma Boilerplate
 
-  
+
 \section{Notation}
 \LMLabel{notation}
 
@@ -104,16 +104,16 @@ Grammar productions are given in a common variant of EBNF.  The left hand side o
 % need a match anything or a production that does that, so we can correct bugs wrt use
 % ~. ~ does not actually parse stuff - it just looks ahead and checks. To get the effect of
 % parsing anything but X, one needs ~X ANYTHING, not just ~X. There are bugs in the
-% grammar related to this. 
-% The alternative is to define ~X as anything but X, or to introduce an anthingBut(X) 
+% grammar related to this.
+% The alternative is to define ~X as anything but X, or to introduce an anthingBut(X)
 % combinator, such as !X
 
 \LMHash{}
-Both syntactic and lexical productions are represented this way. Lexical productions are distinguished by their names. The names of lexical productions consist exclusively of upper case characters and underscores.  As always, within grammatical productions, whitespace and comments between elements of the production are implicitly ignored unless stated otherwise. 
-Punctuation tokens appear in quotes. 
+Both syntactic and lexical productions are represented this way. Lexical productions are distinguished by their names. The names of lexical productions consist exclusively of upper case characters and underscores.  As always, within grammatical productions, whitespace and comments between elements of the production are implicitly ignored unless stated otherwise.
+Punctuation tokens appear in quotes.
 
 \LMHash{}
-Productions are embedded, as much as possible, in the discussion of the constructs they represent. 
+Productions are embedded, as much as possible, in the discussion of the constructs they represent.
 
 \LMHash{}
 A list $x_1, \ldots, x_n$ denotes any list of $n$ elements of the form $x_i, 1 \le i \le n$. Note that $n$ may be zero, in which case the list is empty. We use such lists extensively throughout this specification.
@@ -128,9 +128,9 @@ We sometimes abuse list or map literal syntax, writing $[o_1, \ldots, o_n]$  (re
 The specifications of operators often involve statements such as $x$ $op$ $y$ is equivalent to the method invocation $x.op(y)$. Such specifications should be understood as a shorthand for:
 \begin{itemize}
 \item
- $x$ $op$ $y$ is equivalent to the method invocation $x.op^\prime(y)$, assuming the class of $x$ actually declared a non-operator method named $op^\prime$ defining the same function as the operator $op$. 
+ $x$ $op$ $y$ is equivalent to the method invocation $x.op^\prime(y)$, assuming the class of $x$ actually declared a non-operator method named $op^\prime$ defining the same function as the operator $op$.
  \end{itemize}
- 
+
  \rationale{This circumlocution is required because x.op(y), where op is an operator, is not legal syntax. However, it is painfully verbose, and we prefer to state this rule once here, and use a concise and clear notation across the specification.
  }
 
@@ -141,7 +141,7 @@ When the specification refers to the order given in the program, it means the or
 References to otherwise unspecified names of program entities (such as classes or functions) are interpreted as the names of members of the Dart core library.
 
 \commentary{
-Examples would be the classes \code{Object} and \code{Type} representing the root of the class hierarchy and the reification of runtime types respectively. 
+Examples would be the classes \code{Object} and \code{Type} representing the root of the class hierarchy and the reification of runtime types respectively.
 }
 
 \section{Overview}
@@ -151,15 +151,15 @@ Examples would be the classes \code{Object} and \code{Type} representing the roo
 Dart is a class-based, single-inheritance, pure object-oriented programming language. Dart is optionally typed (\ref{types}) and supports reified generics. The run-time type of every object is represented as an instance of class \code{Type}  which can be obtained by calling the getter  \code{runtimeType} declared in class \code{Object}, the root of the Dart class hierarchy.
 
 \LMHash{}
-Dart programs may be statically checked. The static checker will report some violations of the type rules, but such violations do not abort compilation or preclude execution. 
+Dart programs may be statically checked. The static checker will report some violations of the type rules, but such violations do not abort compilation or preclude execution.
 
 \LMHash{}
-Dart programs may be executed in one of two modes: production mode or checked mode. In production mode, static type annotations (\ref{staticTypes}) have absolutely no effect on execution with the exception of reflection and structural type tests. 
+Dart programs may be executed in one of two modes: production mode or checked mode. In production mode, static type annotations (\ref{staticTypes}) have absolutely no effect on execution with the exception of reflection and structural type tests.
 
 \commentary{
 Reflection, by definition, examines the program structure. If we provide reflective access to the type of a declaration, or to source code, it will inevitably produce results that depend on the types used in the underlying code.
 
-Type tests also examine the types in a program explicitly. Nevertheless, in most cases, these will not depend on type annotations. The exceptions to this rule are type tests involving function types. Function types are structural, and so depend on the types declared for their parameters and on their return types. 
+Type tests also examine the types in a program explicitly. Nevertheless, in most cases, these will not depend on type annotations. The exceptions to this rule are type tests involving function types. Function types are structural, and so depend on the types declared for their parameters and on their return types.
 }
 
 \LMHash{}
@@ -168,17 +168,17 @@ In checked mode, assignments are dynamically checked, and certain violations of
 \commentary{
 The coexistence between optional typing and reification is based on the following:
 \begin{enumerate}
-\item Reified type information reflects the types of objects at runtime and may always be queried by dynamic typechecking constructs (the analogs of instanceOf, casts, typecase etc. in other languages). Reified type information includes class declarations, the runtime type (aka class) of an object, and type arguments to constructors. 
-\item Static type annotations determine the types of variables and function declarations (including methods and constructors). 
+\item Reified type information reflects the types of objects at runtime and may always be queried by dynamic typechecking constructs (the analogs of instanceOf, casts, typecase etc. in other languages). Reified type information includes class declarations, the runtime type (aka class) of an object, and type arguments to constructors.
+\item Static type annotations determine the types of variables and function declarations (including methods and constructors).
 \item Production mode respects optional typing. Static type annotations do not affect runtime behavior.
 \item Checked mode utilizes static type annotations and dynamic type information aggressively yet selectively to provide early error detection during development.
 \end{enumerate}
 }
 
 \LMHash{}
-Dart programs are organized in a modular fashion into units called {\em libraries} (\ref{librariesAndScripts}). Libraries are units of encapsulation and may be mutually recursive. 
+Dart programs are organized in a modular fashion into units called {\em libraries} (\ref{librariesAndScripts}). Libraries are units of encapsulation and may be mutually recursive.
 
-\commentary{However they are not first class.  To get multiple copies of a library running simultaneously, one needs to spawn an isolate. 
+\commentary{However they are not first class.  To get multiple copies of a library running simultaneously, one needs to spawn an isolate.
 }
 
 \subsection{Scoping}
@@ -192,7 +192,7 @@ A scope $S_0$ induces a namespace $NS_0$ that maps the simple name of each varia
 
 \commentary{It is therefore impossible, e.g.,  to define a class that declares a method and a field with the same name in Dart. Similarly one cannot declare a top-level function with the same name as a library variable or class.
   }
-  
+
 \LMHash{}
 It is a compile-time error if there is more than one entity with the same name declared in the same scope.
 
@@ -201,11 +201,11 @@ In some cases, the name of the declaration differs from the identifier used to d
 }
 
 \LMHash{}
-Dart is lexically scoped.    Scopes may nest.  A name or declaration $d$ is {\em available in scope} $S$ if $d$ is in the namespace induced by $S$ or if $d$ is available in the lexically enclosing scope of $S$. We  say that a name or declaration $d$ is {\em in scope} if $d$ is available in the current scope. 
+Dart is lexically scoped.    Scopes may nest.  A name or declaration $d$ is {\em available in scope} $S$ if $d$ is in the namespace induced by $S$ or if $d$ is available in the lexically enclosing scope of $S$. We  say that a name or declaration $d$ is {\em in scope} if $d$ is available in the current scope.
 
 
 \LMHash{}
-If a  declaration $d$ named $n$ is in the namespace induced by a scope $S$, then $d$ {\em hides} any declaration named $n$ that is available in the lexically enclosing scope of $S$. 
+If a  declaration $d$ named $n$ is in the namespace induced by a scope $S$, then $d$ {\em hides} any declaration named $n$ that is available in the lexically enclosing scope of $S$.
 
 \commentary {
 A consequence of these rules is that it is possible to hide a type with a method or variable.
@@ -251,8 +251,8 @@ Now consider the opposite scenario. We start with a version of \code{S} that con
 
 These considerations become even more important if one introduces constructs such as nested classes, which might be considered in future versions of the language.
 
-Good tooling should of course endeavor to inform programmers of such situations (discreetly). For example, an identifier that is both inherited and lexically visible could be highlighted (via underlining or colorization). Better yet, tight integration of source control with language aware tools would detect such changes when they occur. 
- 
+Good tooling should of course endeavor to inform programmers of such situations (discreetly). For example, an identifier that is both inherited and lexically visible could be highlighted (via underlining or colorization). Better yet, tight integration of source control with language aware tools would detect such changes when they occur.
+
 }
 
 
@@ -263,7 +263,7 @@ Good tooling should of course endeavor to inform programmers of such situations
 
 \LMHash{}
 Dart supports two levels of privacy: {\em public} and {\em private}.  A declaration is {\em private} iff its name is private, otherwise it is {\em public.}  A  name $q$ is private iff any one of the identifiers that comprise $q$ is private,  otherwise it is {\em public.}  An identifier is private iff it
-begins with an underscore (the \_ character) otherwise it is {\em public.} 
+begins with an underscore (the \_ character) otherwise it is {\em public.}
 
 \LMHash{}
 A declaration $m$ is {\em accessible to library $L$}  if $m$ is declared in $L$ or if $m$ is public.
@@ -273,7 +273,7 @@ This means private declarations may only be accessed within the library in which
 }
 
 \LMHash{}
-Privacy applies only to declarations within a library, not to library declarations themselves. 
+Privacy applies only to declarations within a library, not to library declarations themselves.
 
 \rationale{Libraries do not reference each other by name and so the idea of a private library is meaningless.
 Thus, if the name of a library begins with an underscore, it has no effect on the accessibility of the library or its members.
@@ -290,7 +290,7 @@ Privacy is indicated by the name of a declaration - hence privacy and naming are
 Dart code is always single threaded. There is no shared-state concurrency in Dart. Concurrency is supported via actor-like entities called {\em isolates}.
 
 \LMHash{}
-An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (\ref{sendingMessages}). No state is ever shared between isolates. Isolates are created by spawning (\ref{spawningAnIsolate}). 
+An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (\ref{sendingMessages}). No state is ever shared between isolates. Isolates are created by spawning (\ref{spawningAnIsolate}).
 
 
 \section{Errors and Warnings}
@@ -300,7 +300,7 @@ An isolate is a unit of concurrency. It has its own memory and its own thread of
 This specification distinguishes between several kinds of errors.
 
 \LMHash{}
-{\em Compile-time errors} are errors that preclude execution. A compile-time error must be reported by a Dart compiler before the erroneous code is executed. 
+{\em Compile-time errors} are errors that preclude execution. A compile-time error must be reported by a Dart compiler before the erroneous code is executed.
 
 \rationale{A Dart implementation has considerable freedom as to when compilation takes place. Modern programming language implementations often interleave compilation and execution, so that compilation of a method may be delayed, e.g.,  until it is first invoked. Consequently, compile-time errors in a method $m$ may be reported as late as the time of $m$'s first invocation.
 
@@ -312,8 +312,8 @@ In a development environment a compiler should of course report compilation erro
 \LMHash{}
 If an uncaught compile-time error occurs within the code of a running isolate $A$, $A$ is immediately suspended.  The only circumstance where a compile-time error could be caught would be via code run reflectively, where the mirror system can catch it.
 
-\rationale{Typically, once a compile-time error is thrown and $A$ is suspended, $A$ will then be terminated. However, this depends on the overall environment. 
-A Dart engine runs in the context of an {\em embedder}, 
+\rationale{Typically, once a compile-time error is thrown and $A$ is suspended, $A$ will then be terminated. However, this depends on the overall environment.
+A Dart engine runs in the context of an {\em embedder},
 a program that interfaces between the engine and the surrounding computing environment. The embedder will often be a web browser, but need not be; it may be a C++ program on the server for example. When an isolate fails with a compile-time error as described above, control returns to the embedder, along with an exception describing the problem.  This is necessary so that the embedder can clean up resources etc. It is then the embedder's decision whether to terminate the isolate or not.
 }
 
@@ -324,23 +324,23 @@ a program that interfaces between the engine and the surrounding computing envir
 {\em Dynamic type errors} are type errors reported in checked mode.
 
 \LMHash{}
-{\em Run-time errors} are exceptions raised during execution. Whenever we say that an exception $ex$ is {\em raised} or {\em thrown}, we mean that a throw expression  (\ref{throw}) of the form: \code{\THROW{} $ex$;} was implicitly evaluated or that a rethrow statement (\ref{rethrow}) of the form \code{\RETHROW} was executed. When we say that {\em a} $C$ {\em is thrown}, where $C$ is a class, we mean that an instance of class $C$ is thrown.
+{\em Run-time errors} are exceptions raised during execution. Whenever we say that an exception $ex$ is {\em raised} or {\em thrown}, we mean that a throw expression  (\ref{throw}) of the form: \code{\THROW{} $ex$;} was implicitly evaluated or that a rethrow statement (\ref{rethrow}) of the form \code{\RETHROW} was executed. When we say that {\em a} $C$ {\em is thrown}, where $C$ is a class, we mean that an instance of class $C$ is thrown. When we say that a stream raises an exception, we mean that an exception occurred while computing the value(s) of the stream.
 
 \LMHash{}
-If an uncaught exception is thrown by a running isolate $A$, $A$ is immediately suspended. 
+If an uncaught exception is thrown by a running isolate $A$, $A$ is immediately suspended.
 
 
 \section{Variables}
 \LMLabel{variables}
 
 \LMHash{}
-Variables are storage locations in memory.  
+Variables are storage locations in memory.
 
 \begin{grammar}
 {\bf variableDeclaration:}
       declaredIdentifier (`,' identifier)*
       .
-      
+
 {\bf declaredIdentifier:}
       metadata finalConstVarOrType identifier
     .
@@ -349,7 +349,7 @@ Variables are storage locations in memory.
            \CONST{} type?;
 	varOrType
     .
-    
+
  {\bf varOrType:}\VAR{};
 	type
     .
@@ -361,7 +361,7 @@ Variables are storage locations in memory.
 {\bf initializedIdentifier:}
       identifier (`=' expression)? % could do top-level here
     .
-    
+
 {\bf initializedIdentifierList:}
       initializedIdentifier (`,' initializedIdentifier)*
     .
@@ -375,22 +375,22 @@ Variables are storage locations in memory.
 A variable that has not been initialized has the initial value \NULL{} (\ref{null}).
 
 \LMHash{}
-A variable declared at the top-level of a library is referred to as either a {\em library variable} or simply a top-level variable. 
+A variable declared at the top-level of a library is referred to as either a {\em library variable} or simply a top-level variable.
 
 \LMHash{}
-A {\em static variable} is a variable that is not associated with a particular instance, but rather with an entire library or class.  Static variables include library variables and class variables. Class variables are variables whose declaration is immediately nested inside a class declaration and includes the modifier \STATIC{}. A library variable is implicitly static. It is a compile-time error to preface a top-level variable declaration with the built-in identifier  (\ref{identifierReference}) \STATIC{}.  
+A {\em static variable} is a variable that is not associated with a particular instance, but rather with an entire library or class.  Static variables include library variables and class variables. Class variables are variables whose declaration is immediately nested inside a class declaration and includes the modifier \STATIC{}. A library variable is implicitly static. It is a compile-time error to preface a top-level variable declaration with the built-in identifier  (\ref{identifierReference}) \STATIC{}.
 
 \LMHash{}
-Static variable declarations are initialized lazily. When a static variable $v$ is read, iff it has not yet been assigned,  it is set to the result of evaluating its initializer. The precise rules are given in section \ref{evaluationOfImplicitVariableGetters}. 
+Static variable declarations are initialized lazily. When a static variable $v$ is read, iff it has not yet been assigned,  it is set to the result of evaluating its initializer. The precise rules are given in section \ref{evaluationOfImplicitVariableGetters}.
 
 \rationale{The lazy semantics are given because we do not want a language where one tends to define expensive initialization computations, causing long application startup times. This is especially crucial for Dart, which must support the coding of  client applications.
 }
 
 \LMHash{}
-A {\em final variable} is a variable whose binding is fixed upon initialization; a final variable $v$ will always refer to the same object after $v$ has been initialized. The declaration of a final variable must  include the modifier \FINAL{}. 
+A {\em final variable} is a variable whose binding is fixed upon initialization; a final variable $v$ will always refer to the same object after $v$ has been initialized. The declaration of a final variable must  include the modifier \FINAL{}.
 
 \LMHash{}
-It is a static warning if a final instance variable that has been initialized at its point of declaration  is  also initialized in a constructor. 
+It is a static warning if a final instance variable that has been initialized at its point of declaration  is  also initialized in a constructor.
 % It is a static warning if a final instance variable that has been initialized by means of an initializing formal of a constructor is  also initialized elsewhere in the same constructor.
 It is a compile-time error if a local variable $v$ is final and $v$ is not initialized at its point of declaration.
 
@@ -410,24 +410,24 @@ A {\em constant variable} is a variable whose declaration includes the modifier
 We say that a variable $v$ is {\em potentially mutated} in some scope $s$ if $v$ is not final or constant and an assignment to $v$ occurs in $s$.
 
 \LMHash{}
-If a variable declaration does not explicitly specify a type, the type of the declared variable(s) is  \DYNAMIC{}, the unknown type (\ref{typeDynamic}). 
+If a variable declaration does not explicitly specify a type, the type of the declared variable(s) is  \DYNAMIC{}, the unknown type (\ref{typeDynamic}).
 
 \LMHash{}
 A variable is {\em mutable} if it is not final.
 Static and instance variable declarations always induce implicit getters. If the variable is mutable it also introduces an implicit setter.
-The scope into which the implicit getters and setters are introduced depends on the kind of variable declaration involved. 
+The scope into which the implicit getters and setters are introduced depends on the kind of variable declaration involved.
 
 \LMHash{}
-A library variable introduces a getter into the top level scope of the enclosing library. A static class variable introduces a static getter into the immediately enclosing class. An instance variable introduces an instance getter into the immediately enclosing class. 
+A library variable introduces a getter into the top level scope of the enclosing library. A static class variable introduces a static getter into the immediately enclosing class. An instance variable introduces an instance getter into the immediately enclosing class.
 
 \LMHash{}
-A mutable library variable introduces a setter into the top level scope of the enclosing library. A mutable static class variable introduces a static setter into the immediately enclosing class. A mutable instance variable introduces an instance setter into the immediately enclosing class. 
+A mutable library variable introduces a setter into the top level scope of the enclosing library. A mutable static class variable introduces a static setter into the immediately enclosing class. A mutable instance variable introduces an instance setter into the immediately enclosing class.
 
 \LMHash{}
 Local variables are added to the innermost enclosing scope.  They do not induce getters and setters.  A local variable may only be referenced at a source code location that is after its initializer, if any, is complete, or a compile-time error occurs.  The error may be reported either at the point where the premature reference occurs, or at the variable declaration.
 
 \rationale {
-We allow the error to be reported at the declaration to allow implementations to avoid an extra processing phase. 
+We allow the error to be reported at the declaration to allow implementations to avoid an extra processing phase.
 }
 
 \commentary{
@@ -438,7 +438,7 @@ The example below illustrates the expected behavior.  A variable $x$ is declared
 \VAR{} x = 0;
 
 f(y) \{
-  \VAR{} z = x; // compile-time error 
+  \VAR{} z = x; // compile-time error
   if (y) \{
     x = x + 1; // two compile time errors
     print(x); // compile time error
@@ -455,7 +455,7 @@ The inner declaration of $x$ is itself erroneous because its right hand side att
 }
 
 \commentary {
-As another example  \code{\VAR{} x = 3, y = x;} is legal, because \code{x} is referenced after its initializer. 
+As another example  \code{\VAR{} x = 3, y = x;} is legal, because \code{x} is referenced after its initializer.
 
 A particularly perverse example involves a local variable name shadowing a type. This is possible because Dart has a single namespace for types, functions and variables.
 }
@@ -473,19 +473,19 @@ perverse() \{
 }
 
 \rationale{
-As a rule, type annotations are ignored in production mode. However, we do 
+As a rule, type annotations are ignored in production mode. However, we do
  not want to allow programs to compile legally in one mode and not another, and in this extremely odd situation, that consideration takes precedence.
 }
 
 \end{dartCode}
 
-% the grammar does not support local getters and setters. The local var discussion does not seem to mention getters and setters based semantics. It simply discusses the creation of the variable, not its access. Access is either assignment or identifiers. Identifiers ignore the getter story. 
+% the grammar does not support local getters and setters. The local var discussion does not seem to mention getters and setters based semantics. It simply discusses the creation of the variable, not its access. Access is either assignment or identifiers. Identifiers ignore the getter story.
 
 \LMHash{}
 The following rules apply to all static and instance variables.
 
 \LMHash{}
-A  variable declaration  of one of the forms \code{$T$ $v$;},  \code{$T$ $v$ = $e$;} ,  \code{\CONST{} $T$ $v$ = $e$;}, \code{\FINAL{} $T$ $v$;}  or \code{\FINAL{} $T$ $v$ = $e$;} always induces an implicit  getter function (\ref{getters}) with signature 
+A  variable declaration  of one of the forms \code{$T$ $v$;},  \code{$T$ $v$ = $e$;} ,  \code{\CONST{} $T$ $v$ = $e$;}, \code{\FINAL{} $T$ $v$;}  or \code{\FINAL{} $T$ $v$ = $e$;} always induces an implicit  getter function (\ref{getters}) with signature
 
 $T$ \GET{} $v$
 
@@ -493,21 +493,21 @@ whose invocation evaluates as described below (\ref{evaluationOfImplicitVariable
 
 
 \LMHash{}
-A  variable declaration  of one of the forms \code{\VAR{} $v$;},  \code{\VAR{} $v$ = $e$;} ,  \code{\CONST{} $v$ = $e$;}, \code{\FINAL{} $v$;} or \code{\FINAL{}  $v$ = $e$;}  always induces an implicit  getter function with signature 
+A  variable declaration  of one of the forms \code{\VAR{} $v$;},  \code{\VAR{} $v$ = $e$;} ,  \code{\CONST{} $v$ = $e$;}, \code{\FINAL{} $v$;} or \code{\FINAL{}  $v$ = $e$;}  always induces an implicit  getter function with signature
 
  \GET{} $v$
 
 whose  invocation evaluates as described below (\ref{evaluationOfImplicitVariableGetters}).
 
 \LMHash{}
-A non-final  variable declaration  of the form \code{{} $T$ $v$;} or the form  \code{$T$ $v$ = $e$;}   always induces an implicit  setter function (\ref{setters}) with signature 
+A non-final  variable declaration  of the form \code{{} $T$ $v$;} or the form  \code{$T$ $v$ = $e$;}   always induces an implicit  setter function (\ref{setters}) with signature
 
  \VOID{} \SET{} $v=(T$ $x)$
 
 whose execution sets the value of $v$ to the incoming argument $x$.
 
 \LMHash{}
-A  non-final variable declaration  of the form \code{\VAR{} $v$;} or the form  \code{\VAR{} $v$ = $e$;}   always induces an implicit  setter function with signature 
+A  non-final variable declaration  of the form \code{\VAR{} $v$;} or the form  \code{\VAR{} $v$ = $e$;}   always induces an implicit  setter function with signature
 
 \SET{} $v=(x)$
 
@@ -519,12 +519,12 @@ whose execution sets the value of $v$ to the incoming argument $x$.
 
 \LMHash{}
 Let $d$ be the declaration of a static or instance variable $v$.  If $d$ is an instance variable, then the invocation of the implicit getter  of $v$ evaluates to the value stored in $v$.
-If $d$ is a static or library variable then the implicit getter method of $v$ executes as follows: 
+If $d$ is a static or library variable then the implicit getter method of $v$ executes as follows:
 \begin{itemize}
-\item {\bf Non-constant variable declaration with initializer}. If $d$ is of one of the forms \code{\VAR{} $v$ = $e$;} ,  \code{$T$ $v$ = $e$;} ,   \code{\FINAL{} $v$ = $e$;} ,  \code{\FINAL{} $T$ $v$ = $e$;}, \code{\STATIC{} $v$ = $e$; }, \code{\STATIC{} $T$ $v$ = $e$; }, \code{\STATIC{} \FINAL{} $v$ = $e$; } or \code{\STATIC{} \FINAL{} $T$ $v$ = $e$;} and no value has yet been stored into $v$ then the initializer expression $e$ is evaluated. If, during the evaluation of $e$, the getter for $v$ is invoked, a \code{CyclicInitializationError} is thrown. If the evaluation succeeded yielding an object $o$, let $r = o$, otherwise let $r = \NULL{}$. In any case, $r$ is stored into $v$. The result of executing the getter is $r$. 
-\item  {\bf Constant variable declaration}. If $d$ is of one of the forms \code{\CONST{} $v$ = $e$; } ,  \code{\CONST{} $T$  $v$ = $e$; },  \code{\STATIC{} \CONST{} $v$ = $e$; }  or \code{\STATIC{} \CONST{} $T$ $v$ = $e$;} the result of the getter is the value of the compile time constant $e$. \commentary{Note that a compile time constant cannot depend on itself, so no cyclic references can occur.} 
+\item {\bf Non-constant variable declaration with initializer}. If $d$ is of one of the forms \code{\VAR{} $v$ = $e$;} ,  \code{$T$ $v$ = $e$;} ,   \code{\FINAL{} $v$ = $e$;} ,  \code{\FINAL{} $T$ $v$ = $e$;}, \code{\STATIC{} $v$ = $e$; }, \code{\STATIC{} $T$ $v$ = $e$; }, \code{\STATIC{} \FINAL{} $v$ = $e$; } or \code{\STATIC{} \FINAL{} $T$ $v$ = $e$;} and no value has yet been stored into $v$ then the initializer expression $e$ is evaluated. If, during the evaluation of $e$, the getter for $v$ is invoked, a \code{CyclicInitializationError} is thrown. If the evaluation succeeded yielding an object $o$, let $r = o$, otherwise let $r = \NULL{}$. In any case, $r$ is stored into $v$. The result of executing the getter is $r$.
+\item  {\bf Constant variable declaration}. If $d$ is of one of the forms \code{\CONST{} $v$ = $e$; } ,  \code{\CONST{} $T$  $v$ = $e$; },  \code{\STATIC{} \CONST{} $v$ = $e$; }  or \code{\STATIC{} \CONST{} $T$ $v$ = $e$;} the result of the getter is the value of the compile time constant $e$. \commentary{Note that a compile time constant cannot depend on itself, so no cyclic references can occur.}
 Otherwise
-\item {\bf Variable declaration without initializer}. The result of executing the getter method is the value stored in $v$.  
+\item {\bf Variable declaration without initializer}. The result of executing the getter method is the value stored in $v$.
 \end{itemize}
 
 
@@ -541,7 +541,7 @@ Functions abstract over executable actions.
 {\bf functionSignature:}
     metadata returnType? identifier formalParameterList
     .
-    
+
 {\bf returnType:}
       \VOID{};
       type
@@ -558,7 +558,7 @@ Functions abstract over executable actions.
 \end{grammar}
 
 \LMHash{}
-Functions include  function declarations (\ref{functionDeclarations}), methods (\ref{instanceMethods},  \ref{staticMethods}), getters  (\ref{getters}), setters  (\ref{setters}), constructors  (\ref{constructors}) and function literals  (\ref{functionExpressions}).  
+Functions include  function declarations (\ref{functionDeclarations}), methods (\ref{instanceMethods},  \ref{staticMethods}), getters  (\ref{getters}), setters  (\ref{setters}), constructors  (\ref{constructors}) and function literals  (\ref{functionExpressions}).
 
 \LMHash{}
 All functions have a signature and a body. The signature describes the formal parameters of the function, and possibly its name and return type.  A function body is either:
@@ -575,31 +575,31 @@ OR
 \end{itemize}
 
 \LMHash{}
-A function is {\em asynchronous} if its body is marked with the \ASYNC{} or \ASYNC* modifier. Otherwise the function is {\em synchronous}. A function is a {\em generator} if its body is marked with the \SYNC* or \ASYNC* modifier.  
+A function is {\em asynchronous} if its body is marked with the \ASYNC{} or \ASYNC* modifier. Otherwise the function is {\em synchronous}. A function is a {\em generator} if its body is marked with the \SYNC* or \ASYNC* modifier.
 
 \commentary{
-Whether a function is synchronous or asynchronous is orthogonal to whether it is a generator or not. Generator functions are a sugar for functions that produce collections in a systematic way, by lazily applying a function that {\em generates} individual elements of a collection. Dart provides such a sugar in both the synchronous case, where one returns an iterable, and in the asynchronous case, where one returns a stream. Dart also allows both synchronous and asynchronous functions that produce a single value. 
+Whether a function is synchronous or asynchronous is orthogonal to whether it is a generator or not. Generator functions are a sugar for functions that produce collections in a systematic way, by lazily applying a function that {\em generates} individual elements of a collection. Dart provides such a sugar in both the synchronous case, where one returns an iterable, and in the asynchronous case, where one returns a stream. Dart also allows both synchronous and asynchronous functions that produce a single value.
 }
 
 \LMHash{}
 It is a compile-time error if an \ASYNC, \ASYNC* or \SYNC* modifier is attached to the body of a setter or constructor.
 
 \rationale{
-An asynchronous setter would be of little use, since setters can only be used in the context of an assignment (\ref{assignment}), and an assignment expression always evaluates to the value of the assignment's right hand side. If the setter actually did its work asynchronously, one might imagine that one would return a future that resolved to the assignment's right hand side after the setter did its work. However, this would require dynamic tests at every assignment, and so would be prohibitively expensive. 
+An asynchronous setter would be of little use, since setters can only be used in the context of an assignment (\ref{assignment}), and an assignment expression always evaluates to the value of the assignment's right hand side. If the setter actually did its work asynchronously, one might imagine that one would return a future that resolved to the assignment's right hand side after the setter did its work. However, this would require dynamic tests at every assignment, and so would be prohibitively expensive.
 
 An asynchronous constructor would, by definition, never return an instance of the class it purports to construct, but instead return a future. Calling such a beast via \NEW{} would be very confusing. If you need to produce an object asynchronously, use a method.
 
 One could allow modifiers for factories. A factory for \code{Future} could be modified by \ASYNC{}, a factory for \code{Stream} could be modified by \ASYNC* and a factory for \code{Iterable} could be modified by \SYNC*. No other scenario makes sense because the object returned by the factory would be of the wrong type. This situation is very unusual so it is not worth making an exception to the general rule for constructors in order to allow it.
 }
 \LMHash{}
-It is a static warning if the declared return type of a function marked \ASYNC{} may not be assigned to \code{Future}. It is a static warning if the declared return type of a function marked \SYNC* may not be assigned to \code{Iterable}. It is a static warning if the declared return type of  a function marked \ASYNC* may not be assigned to \code{Stream}.  
+It is a static warning if the declared return type of a function marked \ASYNC{} may not be assigned to \code{Future}. It is a static warning if the declared return type of a function marked \SYNC* may not be assigned to \code{Iterable}. It is a static warning if the declared return type of  a function marked \ASYNC* may not be assigned to \code{Stream}.
 
 \subsection{Function Declarations}
 \LMLabel{functionDeclarations}
 
 \LMHash{}
-A {\em function declaration} is a function that is neither a member of a class nor a function literal. Function declarations include {\em library functions}, which are function declarations 
-%(including getters and setters) 
+A {\em function declaration} is a function that is neither a member of a class nor a function literal. Function declarations include {\em library functions}, which are function declarations
+%(including getters and setters)
 at the top level of a library, and {\em local functions}, which are function declarations declared inside other functions. Library functions are often referred to simply as top-level functions.
 
 \LMHash{}
@@ -608,7 +608,7 @@ A function declaration consists of an identifier indicating the function's name,
 \LMHash{}
 The scope of a library function is the scope of the enclosing library. The scope of a local function is  described in section \ref{localFunctionDeclaration}. In both cases, the name of the function is in scope in its formal parameter scope (\ref{formalParameters}).
 
-%A function declaration of the form  $T_0$ $id(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{n+k} = d_k])\{s\}$ is equivalent to a variable declaration of the form \code{\FINAL{} $F$ $id$ = $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{n+k}= d_k])\{s\}$}, where $F$ is the function type alias (\ref{typedef}) \code{\TYPEDEF{} $T_0$ $F(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}])$}.  Likewise,  a function declaration of the form  $id(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{n+k} = d_k])\{s\}$ is equivalent to a variable declaration of the form \code{\FINAL{} $F$ $id$ = $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{n+k} = d_k])\{s\}$}, where $F$ is the function type alias \code{\TYPEDEF{}  $F(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}])$}. 
+%A function declaration of the form  $T_0$ $id(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{n+k} = d_k])\{s\}$ is equivalent to a variable declaration of the form \code{\FINAL{} $F$ $id$ = $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{n+k}= d_k])\{s\}$}, where $F$ is the function type alias (\ref{typedef}) \code{\TYPEDEF{} $T_0$ $F(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}])$}.  Likewise,  a function declaration of the form  $id(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{n+k} = d_k])\{s\}$ is equivalent to a variable declaration of the form \code{\FINAL{} $F$ $id$ = $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots, T_{n+k}$ $x_{n+k} = d_k])\{s\}$}, where $F$ is the function type alias \code{\TYPEDEF{}  $F(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}])$}.
 
 %\Q{We need to cover library getters as well.}
 
@@ -646,9 +646,9 @@ The formal parameter list of a function introduces a new scope known as the func
 The body of a function introduces a new scope known as the function's {\em  body scope}. The body scope of a function $f$  is enclosed  in the scope introduced by the formal parameter scope of $f$.
 
 
-%The formal parameter scope of a function maps the name of each formal parameter $p$ to the value $p$ is bound to. 
+%The formal parameter scope of a function maps the name of each formal parameter $p$ to the value $p$ is bound to.
 
-% The formal parameters of a function are processed in the enclosing scope of the function. 
+% The formal parameters of a function are processed in the enclosing scope of the function.
 % \commentary{this means that the parameters themselves may not be referenced within the formal parameter list.}
 
 \LMHash{}
@@ -663,7 +663,7 @@ It is a compile-time error if a formal parameter is declared as a constant varia
 %}
 
 %\begin{grammar}
-%formalParameterList:     
+%formalParameterList:
 %      '(' restFormalParameter? ')';
 %      '(' namedFormalParameters ')';
  %     '(' normalFormalParameters normalFormalParameterTail? ')'
@@ -685,12 +685,12 @@ It is a compile-time error if a formal parameter is declared as a constant varia
     .
 \end{grammar}
 
-%Formal parameters are always \FINAL{}.  
+%Formal parameters are always \FINAL{}.
 %\Q{We're awaiting some data on whether enforcing this would cause widespread pain.}
 %A formal parameter is always considered to be initialized.  \rationale{This is because it will always be initialized by the call - even if it is optional.}
 
 
-\subsubsection{Required Formals} 
+\subsubsection{Required Formals}
 \LMLabel{requiredFormals}
 
 \LMHash{}
@@ -719,7 +719,7 @@ A {\em required formal parameter} may be specified in one of three ways:
 %\subsubsection{Rest Formals}
 %\LMLabel{restFormals}
 
-%A rest formal $R$ must be the last parameter in a formal parameter list.  If a  type $T$ is specified for $R$, it signifies that the type of $R$ is $T[]$. 
+%A rest formal $R$ must be the last parameter in a formal parameter list.  If a  type $T$ is specified for $R$, it signifies that the type of $R$ is $T[]$.
 
 %\begin{grammar}
 %restFormalParameter:
@@ -735,11 +735,11 @@ Optional parameters may be specified and provided with default values.
 \begin{grammar}
 {\bf defaultFormalParameter:}
       normalFormalParameter ('=' expression)?
-    .   
-        
+    .
+
 {\bf defaultNamedParameter:}
       normalFormalParameter ( `{\escapegrammar :}' expression)?
-    .   
+    .
 \end{grammar}
 
 \LMHash{}
@@ -750,7 +750,7 @@ It is a compile-time error if the name of a named optional parameter begins with
 
 \rationale{
 The need for this  restriction is a direct consequence of the fact that naming and privacy are not orthogonal.
-If we allowed named parameters to begin with an underscore, they would be considered private and inaccessible to callers from outside the library where it was defined. If a method outside the library overrode a method with a private optional name, it would not be a subtype of the original method. The static checker would of course flag such situations, but the consequence would be that adding a private named formal would break clients outside the library in a way they could not easily correct. 
+If we allowed named parameters to begin with an underscore, they would be considered private and inaccessible to callers from outside the library where it was defined. If a method outside the library overrode a method with a private optional name, it would not be a subtype of the original method. The static checker would of course flag such situations, but the consequence would be that adding a private named formal would break clients outside the library in a way they could not easily correct.
 }
 
 \subsection{Type of a Function}
@@ -769,7 +769,7 @@ Let $F$ be a function with required formal parameters $T_1$ $p_1 \ldots, T_n$ $p
 Let $F$ be a function with required formal parameters $T_1$ $p_1 \ldots, T_n$ $p_n$, return type $T_0$ and named optional parameters $T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$ $ p_{n+k}$. Then the type of $F$ is $(T_1 ,\ldots, T_n, \{T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$  $p_{n+k}\}) \rightarrow T_0$.
 
 \LMHash{}
-The run time type of a function object always implements the class \cd{Function}. 
+The run time type of a function object always implements the class \cd{Function}.
 
 \commentary{
 One cannot assume, based on the above, that  given a function \cd{f}, \cd{f.runtimeType} will actually be \cd{Function}, or that any two distinct function objects necessarily have the same runtime type.
@@ -785,10 +785,10 @@ For example, consider that a closure produced via property extraction treats equ
 \LMLabel{externalFunctions}
 
 \LMHash{}
-An {\em external function} is a function whose body is provided separately from its declaration. An external function may be a top-level function (\ref{librariesAndScripts}), a method (\ref{instanceMethods}, \ref{staticMethods}), a getter (\ref{getters}), a setter (\ref{setters}) or a non-redirecting constructor (\ref{generativeConstructors}, \ref{factories}). External functions are introduced via the built-in identifier \EXTERNAL{}  (\ref{identifierReference}) followed by the function signature.  
+An {\em external function} is a function whose body is provided separately from its declaration. An external function may be a top-level function (\ref{librariesAndScripts}), a method (\ref{instanceMethods}, \ref{staticMethods}), a getter (\ref{getters}), a setter (\ref{setters}) or a non-redirecting constructor (\ref{generativeConstructors}, \ref{factories}). External functions are introduced via the built-in identifier \EXTERNAL{}  (\ref{identifierReference}) followed by the function signature.
 
 \rationale{
-External functions allow us to introduce  type information for code that is not statically known to the Dart compiler. 
+External functions allow us to introduce  type information for code that is not statically known to the Dart compiler.
 }
 
 \commentary{
@@ -811,10 +811,10 @@ A {\em class} defines the form and behavior of a set of objects which are its {\
 {\bf classDefinition:}
 metadata \ABSTRACT{}?  \CLASS{} identifier typeParameters? (superclass mixins?)? interfaces? \\
        `\{' (metadata classMemberDefinition)* `\}';
-       
+
 metadata \ABSTRACT{}?  \CLASS{} mixinApplicationClass
     .
-    
+
 {\bf mixins:}
   \WITH{} typeList
   .
@@ -860,7 +860,7 @@ A class has constructors,  instance members and static members. The instance mem
 
 A class has several scopes:
 \begin{itemize}
-\item A {\em type-parameter scope}, which is empty if the class is not generic (\ref{generics}).  The enclosing scope of the type-parameter scope of a class is the enclosing scope of the class declaration. 
+\item A {\em type-parameter scope}, which is empty if the class is not generic (\ref{generics}).  The enclosing scope of the type-parameter scope of a class is the enclosing scope of the class declaration.
 \item A {\em static scope}. The enclosing scope of the static scope of a  class is the type parameter scope (\ref{generics}) of the class.
 \item  An {\em instance scope}.
 The enclosing scope of a class' instance scope is the class' static scope.
@@ -873,14 +873,14 @@ The enclosing scope of a static member declaration is the static scope of the cl
 
 \LMHash{}
 Every class has a single superclass  except class \code{Object} which has no superclass. A class may implement a number of interfaces
-%, either 
+%, either
 by declaring them in its implements clause  (\ref{superinterfaces}).
 % or via interface injection declarations (\ref{interfaceInjection}) outside the class declaration
 
 
 \LMHash{}
-An {\em abstract class} is 
-%either 
+An {\em abstract class} is
+%either
 a class that is explicitly declared with the  \ABSTRACT{}  modifier, either by means of a class declaration or via a type alias (\ref{typedef}) for a mixin application (\ref{mixinApplication}). A {\em concrete class} is a class that is not abstract.
 %, or a class that declares at least one abstract method  (\ref{abstractInstanceMembers}).
 
@@ -900,7 +900,7 @@ The {\em interface of class $C$} is an implicit interface that declares instance
 \LMHash{}
  It is a compile-time error if a class declares two members of the same name.
  %, except that a getter and a setter may be declared with the same name provided both are instance members or both are static members.
-It is a compile-time error if a class has an instance member and a static member  with the same name. 
+It is a compile-time error if a class has an instance member and a static member  with the same name.
 % It is a compile-time error if a generic (\ref{generics}) class declares a member with the same name as one of its type parameters.
 
 \commentary{Here are simple examples, that illustrate the difference between ``has a member'' and ``declares a member''. For example, \code{B} {\em declares} one member named \code{f}, but {\em has} two such members. The rules of inheritance determine what members a class has.
@@ -915,11 +915,11 @@ It is a compile-time error if a class has an instance member and a static member
 
 \CLASS{} B \EXTENDS{} A \{
   int i = 1; //  getter i and setter i= override versions from A
-  \STATIC{} j; // compile-time error: static getter \& setter conflict with 
+  \STATIC{} j; // compile-time error: static getter \& setter conflict with
   //instance getter \& setter
-  
+
   /* compile-time error: static method conflicts with instance method */
-  \STATIC{} f(x) =$>$ 3; 
+  \STATIC{} f(x) =$>$ 3;
 \}
 \end{dartCode}
 
@@ -935,7 +935,7 @@ Instance methods are functions (\ref{functions}) whose declarations are immediat
 %make these warnings if possible
 
 \LMHash{}
-It is a static warning if an instance method $m_1$ overrides  (\ref{inheritanceAndOverriding}) an instance member $m_2$ and  $m_1$ has a greater number of required parameters than $m_2$. It is a static warning if an instance method $m_1$ overrides  an instance member $m_2$ and  $m_1$ has fewer positional parameters than $m_2$.  It is a static warning if an instance method $m_1$ overrides  an instance member $m_2$ and  $m_1$ does not declare all the named parameters declared by $m_2$. 
+It is a static warning if an instance method $m_1$ overrides  (\ref{inheritanceAndOverriding}) an instance member $m_2$ and  $m_1$ has a greater number of required parameters than $m_2$. It is a static warning if an instance method $m_1$ overrides  an instance member $m_2$ and  $m_1$ has fewer positional parameters than $m_2$.  It is a static warning if an instance method $m_1$ overrides  an instance member $m_2$ and  $m_1$ does not declare all the named parameters declared by $m_2$.
 
 % not quite right. It should be ok to override a method that requires N parameters with one that requires M < N but accepts the others as optional.
 
@@ -949,13 +949,13 @@ It is a static warning if an instance method $m_1$ overrides an instance member
 \LMLabel{operators}
 
 \LMHash{}
-{\em Operators} are instance methods with special names. 
+{\em Operators} are instance methods with special names.
 
 \begin{grammar}
 {\bf operatorSignature:}
        returnType? \OPERATOR{} operator formalParameterList
        .
-       
+
  {\bf operator:}`\~{}';
       binaryOperator;
       `[' `]' ;
@@ -979,10 +979,10 @@ The following names are allowed for user-defined operators: \code{$<$, $>$, $<$=
 
 
 \LMHash{}
-It is a compile-time error if the arity of the user-declared operator \code{[]=} is not 2. It is a compile-time error if the arity of a user-declared operator with one of the names:  \code{ $<$, $>$, $<$=, $>$=, ==, -, +,  \~{}/, /, *, \%, $|$, \^{}, \&, $<<$, $>>$, []} is not 1. It is a compile-time error if the arity of the user-declared operator  \code{-} is not 0 or 1. 
+It is a compile-time error if the arity of the user-declared operator \code{[]=} is not 2. It is a compile-time error if the arity of a user-declared operator with one of the names:  \code{ $<$, $>$, $<$=, $>$=, ==, -, +,  \~{}/, /, *, \%, $|$, \^{}, \&, $<<$, $>>$, []} is not 1. It is a compile-time error if the arity of the user-declared operator  \code{-} is not 0 or 1.
 
 \commentary{
-The \code{-} operator is unique in that two overloaded versions are permitted. If the operator has no arguments, it denotes unary minus. If it has an argument, it denotes binary subtraction. 
+The \code{-} operator is unique in that two overloaded versions are permitted. If the operator has no arguments, it denotes unary minus. If it has an argument, it denotes binary subtraction.
 }
 
 \LMHash{}
@@ -993,7 +993,7 @@ This device allows the two methods to be distinguished for purposes of method lo
 }
 
 \LMHash{}
-It is a compile-time error if the arity of the user-declared operator  \code{ \~{}} is not 0. 
+It is a compile-time error if the arity of the user-declared operator  \code{ \~{}} is not 0.
 
 \LMHash{}
 It is a compile-time error to declare an optional parameter in an operator.
@@ -1004,7 +1004,7 @@ It is a static warning if the return type of the user-declared operator \code{[]
 % add rationale: return in []= methods will have no effect, a the expression always returns its second argument (the RHS of the assignment, for consistency with assignment in general). So it's best to enforce this by declaring the method to be void, even though the expression that uses it returns an object with the type of the RHS, as described in \ref{assignment}.
 
 
-\subsection{Getters} 
+\subsection{Getters}
 \LMLabel{getters}
 
 \LMHash{}
@@ -1012,7 +1012,7 @@ Getters are functions (\ref{functions})  that are used to retrieve the values of
 
 \begin{grammar}
 {\bf getterSignature:}
-       returnType? \GET{} identifier 
+       returnType? \GET{} identifier
 .
 \end{grammar}
 
@@ -1033,13 +1033,13 @@ The instance getters of a class $C$ are those instance getters declared by $C$,
 It is a compile-time error if a class has both a getter and a method with the same name. This restriction holds regardless of whether the getter is defined explicitly or implicitly, or whether the getter or the method are inherited or not.
 
 \commentary{
-This implies that a getter can never override a method, and a method can never override a getter or field. 
+This implies that a getter can never override a method, and a method can never override a getter or field.
 }
 
 \LMHash{}
 It is a static warning if the return type of a getter is \VOID.
-It is a static warning if a getter $m_1$ overrides  (\ref{inheritanceAndOverriding}) a getter 
-$m_2$ and the type of $m_1$ is not a subtype of the type of $m_2$.   
+It is a static warning if a getter $m_1$ overrides  (\ref{inheritanceAndOverriding}) a getter
+$m_2$ and the type of $m_1$ is not a subtype of the type of $m_2$.
 
 \LMHash{}
 It is a static warning if a class  declares a static getter named $v$ and also has a non-static setter named $v=$. It is a static warning if a class $C$ declares an instance getter named $v$ and an accessible static member named $v$ or $v=$ is declared in a superclass of $C$. These warnings must be issued regardless of whether the getters or setters are declared explicitly or implicitly.
@@ -1076,7 +1076,7 @@ It is a compile-time error if a setter's formal parameter list does not consist
 
 \LMHash{}
 It is a static warning if a setter declares a return type other than \VOID{}.
-It is a static warning if a setter $m_1$ overrides  (\ref{inheritanceAndOverriding}) a setter $m_2$ and the type of $m_1$ is not a subtype of the type of $m_2$. It is a static warning if a class has a setter named $v=$ with argument type $T$ and a getter named $v$ with return type $S$, and $T$ may not be assigned to $S$. 
+It is a static warning if a setter $m_1$ overrides  (\ref{inheritanceAndOverriding}) a setter $m_2$ and the type of $m_1$ is not a subtype of the type of $m_2$. It is a static warning if a class has a setter named $v=$ with argument type $T$ and a getter named $v$ with return type $S$, and $T$ may not be assigned to $S$.
 
 \LMHash{}
 It is a static warning if a class  declares a static setter named $v=$ and also has a non-static member named $v$. It is a static warning if a class $C$ declares an instance setter named $v=$ and an accessible static member named $v=$ or $v$ is declared in a superclass of $C$.
@@ -1114,7 +1114,7 @@ The purpose of an abstract method is to provide a declaration for purposes such
 \LMHash{}
 It is a static warning if an abstract member $m$ is declared or inherited in a concrete class $C$ unless:
 \begin{itemize}
-\item  $m$ overrides a concrete member, or 
+\item  $m$ overrides a concrete member, or
 \item $C$ has a \cd{noSuchMethod()} method distinct from the one declared in class \cd{Object}.
 \end{itemize}
 
@@ -1150,20 +1150,20 @@ It is a compile-time error if an instance variable is declared to be constant.
 The notion of a constant instance variable is subtle and confusing to programmers.
 An instance variable is intended to vary per instance. A constant instance variable would have the same value for all instances, and as such is already a dubious idea.
 
-The language could interpret const instance variable declarations as instance getters that return a constant.  However, a constant instance variable could not be treated as a true compile time constant, as its getter would be subject to overriding.   
+The language could interpret const instance variable declarations as instance getters that return a constant.  However, a constant instance variable could not be treated as a true compile time constant, as its getter would be subject to overriding.
 
 Given that the value does not depend on  the instance, it is better to use a static class variable.
 An instance getter for it can always be defined manually if desired.
 }
 
 
-%An instance variable declaration of one of the forms \code{$T$ $v$;}, \code{\FINAL{} $T$ $v$;} ,  \code{$T$ $v$ = $e$;} ,  \code{\CONST{} $T$ $v$ = $e$;} or \code{\FINAL{} $T$ $v$ = $e$;}  always induces an implicit getter function (\ref{getters}) with signature 
+%An instance variable declaration of one of the forms \code{$T$ $v$;}, \code{\FINAL{} $T$ $v$;} ,  \code{$T$ $v$ = $e$;} ,  \code{\CONST{} $T$ $v$ = $e$;} or \code{\FINAL{} $T$ $v$ = $e$;}  always induces an implicit getter function (\ref{getters}) with signature
 
 %$T$ \GET{} $v$
 
 %whose invocation evaluates to the value stored in $v$.
 
-%An instance variable declaration  of one of the forms \code{\VAR{} $v$;}, \code{\FINAL{} $v$;}, \code{\VAR{} $v$ = $e$;} ,  \code{\CONST{} $v$ = $e$;} or \code{\FINAL{} $v$ = $e$;}   always induces an implicit getter function with signature 
+%An instance variable declaration  of one of the forms \code{\VAR{} $v$;}, \code{\FINAL{} $v$;}, \code{\VAR{} $v$ = $e$;} ,  \code{\CONST{} $v$ = $e$;} or \code{\FINAL{} $v$ = $e$;}   always induces an implicit getter function with signature
 
 %\GET{} $v$
 
@@ -1171,13 +1171,13 @@ An instance getter for it can always be defined manually if desired.
 
 %\commentary{Getters are introduced for all instance and static variables (\ref{staticVariables}), regardless of whether they are const/final or not.}
 
-%A non-final instance variable declaration  of the form \code{$T$ $v$;} or the form  \code{$T$ $v$ = $e$;}   always induces an implicit setter function (\ref{setters}) with signature 
+%A non-final instance variable declaration  of the form \code{$T$ $v$;} or the form  \code{$T$ $v$ = $e$;}   always induces an implicit setter function (\ref{setters}) with signature
 
 %\VOID{} \SET{} $v=(T$ $x)$
 
 %whose execution sets the value of $v$ to the incoming argument $x$.
 
-%A non-final instance variable declaration  of the form \code{\VAR{} $v$;} or the form  \code{\VAR{} $v$ = $e$;}   always induces an implicit setter function with signature 
+%A non-final instance variable declaration  of the form \code{\VAR{} $v$;} or the form  \code{\VAR{} $v$ = $e$;}   always induces an implicit setter function with signature
 
 %\SET{} $v=(x)$
 
@@ -1190,15 +1190,15 @@ An instance getter for it can always be defined manually if desired.
 \LMLabel{constructors}
 
 \LMHash{}
-A {\em constructor} is a special function that is used in instance creation expressions (\ref{instanceCreation}) to produce objects. Constructors may be generative (\ref{generativeConstructors}) or they may be factories (\ref{factories}). 
+A {\em constructor} is a special function that is used in instance creation expressions (\ref{instanceCreation}) to produce objects. Constructors may be generative (\ref{generativeConstructors}) or they may be factories (\ref{factories}).
 
 \LMHash{}
-A {\em constructor name} always begins with the name of its immediately enclosing class, and may optionally be followed by a dot and an identifier $id$. It is a compile-time error if $id$ is the name of a member  declared in the immediately enclosing class. It is a compile-time error if the name of a  constructor is not a constructor name. 
+A {\em constructor name} always begins with the name of its immediately enclosing class, and may optionally be followed by a dot and an identifier $id$. It is a compile-time error if $id$ is the name of a member  declared in the immediately enclosing class. It is a compile-time error if the name of a  constructor is not a constructor name.
 
 
 % In what scope do constructors go? The simple names of named constructors go  in the static scope of the class. Unnamed ones go nowhere, but we use the class name to refer to them; the class name could also in the static scope of the class as well to prevent weird errors, or we could ban it explicitly and avoiding duplication. Similarly, the instance scope could contain the constructor names and class name, or we could have special rules to prevent collisions between instance members and constructors or the class.
 
-% The enclosing scope of a generative constructor is the instance scope of the class in which it is declared (but what about redirecting?) 
+% The enclosing scope of a generative constructor is the instance scope of the class in which it is declared (but what about redirecting?)
 
 \LMHash{}
 Iff no constructor is specified for a class $C$, it implicitly has a default constructor \code{C() : \SUPER{}() \{\}}, unless $C$ is class \code{Object}.
@@ -1216,7 +1216,7 @@ A {\em generative constructor} consists of a constructor name, a constructor par
  \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. 
+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}$.
@@ -1242,14 +1242,14 @@ class A \{
 \commentary{is legal, and has the same effect as}
 
 \begin{dartCode}
-class A \{ 
+class A \{
   int x;
   A([int x]): this.x = x;
 \}
 \end{dartCode}
 
 \LMHash{}
-A {\em fresh instance} is an instance whose identity  is distinct from any previously allocated instance of its class. A generative constructor always operates on a fresh instance of its immediately enclosing class. 
+A {\em fresh instance} is an instance whose identity  is distinct from any previously allocated instance of its class. A generative constructor always operates on a fresh instance of its immediately enclosing class.
 
 \commentary{
 The above holds if the constructor is actually run, as it is by \NEW{}. If a constructor $c$ is referenced by \CONST{}, $c$ may not be run; instead, a canonical object may be looked up. See the section on instance creation (\ref{instanceCreation}).
@@ -1284,7 +1284,7 @@ An initializer list begins with a colon, and consists of a comma-separated list
 \begin{itemize}
 \item A {\em superinitializer} identifies a {\em superconstructor} - that is, a specific  constructor of the superclass.  Execution of the superinitializer causes the initializer list of the superconstructor to be executed.
 
-\item An {\em instance variable initializer} assigns a value to an individual instance variable. 
+\item An {\em instance variable initializer} assigns a value to an individual instance variable.
 \end{itemize}
 
 \begin{grammar}
@@ -1297,7 +1297,7 @@ An initializer list begins with a colon, and consists of a comma-separated list
       \SUPER{} `{\escapegrammar .}' identifier arguments;
      fieldInitializer
     .
-    
+
    {\bf  fieldInitializer:}
       (\THIS{} `{\escapegrammar .}')? identifier `=' conditionalExpression cascadeSection*
     .
@@ -1306,35 +1306,35 @@ An initializer list begins with a colon, and consists of a comma-separated list
 
 \LMHash{}
 Let $k$ be a generative constructor.  Then $k$ may include at most one  superinitializer in its initializer list or a compile-time error occurs. If no superinitializer is provided, an implicit superinitializer of the form \SUPER{}() is added at the end of $k$'s initializer list, unless the enclosing class is class \code{Object}. It is a compile-time error if more than one initializer corresponding to a given instance variable appears in $k$'s initializer list. It is a compile-time error if $k$'s initializer list contains an initializer for a variable that is initialized by means of an initializing formal of $k$. % It is a compile-time error if  $k$'s initializer list contains an initializer for a final variable $f$ whose declaration includes an initialization expression.
- 
+
 \LMHash{}
 Each final instance variable $f$ declared in the immediately enclosing class must have an initializer in $k$'s initializer list unless it has already been initialized by one of the following means:
  \begin{itemize}
  \item Initialization at the declaration of $f$.
  \item Initialization by  means of an initializing formal of $k$.
  \end{itemize}
- 
+
 or a static warning occurs. It is a compile-time error if $k$'s initializer list contains an initializer for a variable that is not an instance variable declared in the immediately surrounding class.
 
- 
-\commentary{The  initializer list may of course contain an initializer for any  instance variable declared by the immediately surrounding class, even if it is not final. 
+
+\commentary{The  initializer list may of course contain an initializer for any  instance variable declared by the immediately surrounding class, even if it is not final.
 }
 
 \LMHash{}
- It is a compile-time error if a  generative constructor of class \code{Object} includes a superinitializer. 
+ It is a compile-time error if a  generative constructor of class \code{Object} includes a superinitializer.
 
 \LMHash{}
-Execution of a generative constructor $k$ is always done with respect to a set of bindings for its formal parameters and with  \THIS{} bound to a fresh instance $i$ and the type parameters of the immediately enclosing class bound to a set of actual type arguments $V_1, \ldots , V_m$. 
+Execution of a generative constructor $k$ is always done with respect to a set of bindings for its formal parameters and with  \THIS{} bound to a fresh instance $i$ and the type parameters of the immediately enclosing class bound to a set of actual type arguments $V_1, \ldots , V_m$.
 
 \commentary{These bindings are usually determined by the instance creation expression that invoked the constructor (directly or indirectly). However, they may also be determined by a reflective call,.
 }
 
 \LMHash{}
-If $k$ is redirecting then its redirect clause has the form 
+If $k$ is redirecting then its redirect clause has the form
 
-\THIS{}$.g(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ 
+\THIS{}$.g(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$
 
-where $g$ identifies another  generative constructor of the immediately surrounding class. Then execution of $k$ proceeds by evaluating the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$, and then executing $g$ with respect to the bindings resulting from the evaluation of $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ and with  \THIS{} bound to $i$ and the type parameters of the immediately enclosing class bound to $V_1, \ldots , V_m$. 
+where $g$ identifies another  generative constructor of the immediately surrounding class. Then execution of $k$ proceeds by evaluating the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$, and then executing $g$ with respect to the bindings resulting from the evaluation of $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ and with  \THIS{} bound to $i$ and the type parameters of the immediately enclosing class bound to $V_1, \ldots , V_m$.
 
 \LMHash{}
 Otherwise, execution  proceeds as follows:
@@ -1342,7 +1342,7 @@ Otherwise, execution  proceeds as follows:
 \LMHash{}
 %First, a fresh instance (\ref{generativeConstructors}) $i$ of the immediately enclosing class is allocated.  Next, the instance variable declarations of the immediately enclosing class are visited in the order they appear in the program text. For each such declaration $d$, if $d$ has the form  \code{$finalConstVarOrType$ $v$ = $e$; } then the instance variable $v$ of $i$ is bound to the value of $e$ (which is necessarily a compile-time constant).
 %Next, a
-Any initializing formals declared in $k$'s parameter list are executed in the order they appear in the program text.  
+Any initializing formals declared in $k$'s parameter list are executed in the order they appear in the program text.
 % In fact, this order is unobservable; this could be done any time prior to running the body, since
 % these only effect \THIS{}.
 Then, $k$'s  initializers are executed in the order they appear in the program.
@@ -1353,7 +1353,7 @@ Then, $k$'s  initializers are executed in the order they appear in the program.
 After all the initializers  have completed, the body of $k$ is executed  in a scope where \THIS{} is bound to $i$. Execution of the body begins with execution of the body of the superconstructor  with \THIS{} bound to $i$, the type parameters of the immediately enclosing class bound to a set of actual type arguments $V_1, \ldots , V_m$ and the formal parameters bindings determined by the argument list of the superinitializer of $k$.
 
 \rationale{
-This process ensures that no uninitialized final field is ever seen by code. Note that \THIS{} is not in scope on the right hand side of an initializer (see \ref{this}) so no instance method can execute during initialization: an instance method cannot be directly invoked, nor can  \THIS{} be passed into any other code being invoked in the initializer. 
+This process ensures that no uninitialized final field is ever seen by code. Note that \THIS{} is not in scope on the right hand side of an initializer (see \ref{this}) so no instance method can execute during initialization: an instance method cannot be directly invoked, nor can  \THIS{} be passed into any other code being invoked in the initializer.
 }
 
 \LMHash{}
@@ -1363,14 +1363,14 @@ Execution of an initializer of the form \code{\THIS{}.$v$ = $e$} proceeds as fol
 First, the expression $e$ is evaluated to an object $o$. Then, the instance variable $v$ of the object denoted by \THIS{} is bound to $o$, unless $v$ is a final variable that has already been initialized, in which case a runtime error occurs. In checked mode, it is a dynamic type error if $o$ is not \NULL{} and the interface of the class of $o$ is not a subtype of the actual type of the field $v$.
 
 \LMHash{}
-An initializer of the form \code{$v$ = $e$} is equivalent to an initializer of the form  \code{\THIS{}.$v$ = $e$}. 
+An initializer of the form \code{$v$ = $e$} is equivalent to an initializer of the form  \code{\THIS{}.$v$ = $e$}.
 
 \LMHash{}
-Execution of a superinitializer of the form 
+Execution of a superinitializer of the form
 
-\SUPER{}$(a_1, \ldots, a_n,  x_{n+1}: a_{n+1}, \ldots, x_{n+k}: a_{n+k})$ 
+\SUPER{}$(a_1, \ldots, a_n,  x_{n+1}: a_{n+1}, \ldots, x_{n+k}: a_{n+k})$
 
-(respectively  \SUPER{}$.id(a_1, \ldots, a_n, x_{n+1}: a_{n+1}, \ldots, x_{n+k}: a_{n+k})$ 
+(respectively  \SUPER{}$.id(a_1, \ldots, a_n, x_{n+1}: a_{n+1}, \ldots, x_{n+k}: a_{n+k})$
 
 proceeds as follows:
 
@@ -1390,7 +1390,7 @@ It is a compile-time error if class $S$ does not declare a generative constructo
 \LMLabel{factories}
 
 \LMHash{}
-A {\em factory} is a constructor prefaced by the built-in identifier  (\ref{identifierReference})   \FACTORY{}. 
+A {\em factory} is a constructor prefaced by the built-in identifier  (\ref{identifierReference})   \FACTORY{}.
 
 \begin{grammar}
 {\bf factoryConstructorSignature:}
@@ -1405,7 +1405,7 @@ A {\em factory} is a constructor prefaced by the built-in identifier  (\ref{iden
 The {\em return type} of a factory whose signature is of the form \FACTORY{} $M$ or the form \FACTORY{} $M.id$ is $M$ if $M$ is not a generic type; otherwise the return type is  $M <T_1, \ldots, T_n>$ where $T_1, \ldots, T_n$ are the type parameters of the enclosing class
 
 \LMHash{}
-It is a compile-time error if $M$ is not the name of the immediately enclosing class. 
+It is a compile-time error if $M$ is not the name of the immediately enclosing class.
 
 \LMHash{}
 In checked mode, it is a dynamic type error if a factory returns a non-null object whose type is not a subtype of its actual (\ref{actualTypeOfADeclaration}) return type.
@@ -1413,7 +1413,7 @@ In checked mode, it is a dynamic type error if a factory returns a non-null obje
 \rationale{It seems useless to allow a factory to return null. But it is more uniform to allow it, as the rules currently do.}
 
 \rationale{Factories address classic weaknesses associated with constructors in other languages.
-Factories can produce instances that are not freshly allocated: they can come from a cache. Likewise, factories can return instances of different classes. 
+Factories can produce instances that are not freshly allocated: they can come from a cache. Likewise, factories can return instances of different classes.
 
 }
 
@@ -1430,7 +1430,7 @@ A {\em redirecting factory constructor} specifies a call to a constructor of ano
 \end{grammar}
 
 \LMHash{}
-Calling a redirecting factory constructor $k$ causes the constructor $k^\prime$ denoted by $type$ (respectively, $type.identifier$) to be called with the actual arguments passed to $k$, and returns the result of $k^\prime$ as the result of $k$.  The resulting constructor call is governed by the same rules as an instance creation expression using \NEW{} (\ref{instanceCreation}). 
+Calling a redirecting factory constructor $k$ causes the constructor $k^\prime$ denoted by $type$ (respectively, $type.identifier$) to be called with the actual arguments passed to $k$, and returns the result of $k^\prime$ as the result of $k$.  The resulting constructor call is governed by the same rules as an instance creation expression using \NEW{} (\ref{instanceCreation}).
 
 \commentary{
 It follows that if $type$ or $type.id$ are not defined, or do not refer to a class or constructor, a dynamic error occurs, as with any other undefined constructor call. The same holds if $k$ is called with fewer required parameters or more positional parameters than $k^\prime$ expects, or if $k$  is called with a named parameter that is not declared by $k^\prime$.
@@ -1448,14 +1448,14 @@ It is a run-time error if a redirecting factory constructor redirects to itself,
 
 \rationale{
 If a redirecting factory $F_1$ redirects to another redirecting factory $F_2$ and $F_2$ then redirects to $F_1$, then both $F_1$ and $F_2$ are ill-defined. Such cycles are therefore illegal.
-} 
+}
 
 
 \LMHash{}
 It is a static warning if $type$ does not denote a class accessible in the current scope; if $type$ does denote such a class $C$ it is a static warning if the referenced constructor (be it $type$ or $type.id$) is not a constructor of $C$.
 
 \commentary{
-Note that it is not possible to modify the arguments being passed to  $k'$.  
+Note that it is not possible to modify the arguments being passed to  $k'$.
 }
 % but we have the same issue with other redirecting constructors, no?)
 \rationale{
@@ -1485,7 +1485,7 @@ At first glance, one might think that ordinary factory constructors could simply
 %}
 
 %\CLASS{} A$<$T$>${
-%  \FACTORY{} A.idw(w) $=>$ F$<$T$>$.idw(w); 
+%  \FACTORY{} A.idw(w) $=>$ F$<$T$>$.idw(w);
 %// illegal - cannot pass type parameter to static method
 %  \FACTORY{} A.idx(x) $=> \NEW{} $F$<$T$>$.idx(x); // works, but allocates a gratuitous instance of F
 %  \FACTORY{} A.idy(y) = Y$<$T$>$; // works
@@ -1511,7 +1511,7 @@ It is a static type warning if any of the type arguments to $k^\prime$ are not s
 \LMLabel{constantConstructors}
 
 \LMHash{}
-A {\em constant constructor} may be used to create compile-time constant  (\ref{constants}) objects. A constant constructor is prefixed by the reserved word \CONST{}. 
+A {\em constant constructor} may be used to create compile-time constant  (\ref{constants}) objects. A constant constructor is prefixed by the reserved word \CONST{}.
 
 \begin{grammar}
 {\bf constantConstructorSignature:}
@@ -1527,7 +1527,7 @@ A {\em constant constructor} may be used to create compile-time constant  (\ref{
 \commentary{All the work of a constant constructor must be handled via its initializers.}
 
 \LMHash{}
-It is a compile-time error if a constant constructor is declared by a class that has a non-final instance variable.  
+It is a compile-time error if a constant constructor is declared by a class that has a non-final instance variable.
 
 \commentary{
 The above refers to both locally declared and inherited instance variables.
@@ -1544,7 +1544,7 @@ A superclass of $C$ cannot declare such an initializer either, because it must n
 The superinitializer that appears, explicitly or implicitly, in the initializer list of a constant constructor must specify a constant constructor of the superclass of the immediately enclosing class or a compile-time error occurs.
 
 \LMHash{}
-Any expression that appears within the initializer list of a constant constructor must be a potentially constant expression, or a compile-time error occurs. 
+Any expression that appears within the initializer list of a constant constructor must be a potentially constant expression, or a compile-time error occurs.
 
 \LMHash{}
 A {\em potentially constant expression} is an expression $e$ that would be a valid constant expression if all formal parameters of $e$'s immediately enclosing constant constructor were treated as compile-time constants that were guaranteed to evaluate to an integer, boolean or string value as required by their immediately enclosing superexpression, <em>and</em> where $e$ is also a valid expression if all the formal parameters are treated as non-constant variables.
@@ -1564,9 +1564,9 @@ Note that a parameter that is not used in a superexpression that is restricted t
 
 
 \commentary{
-The difference between a potentially constant expression and a compile-time constant expression (\ref{const}) deserves some explanation. 
+The difference between a potentially constant expression and a compile-time constant expression (\ref{const}) deserves some explanation.
 
-The key issue is whether one treats the formal parameters of a constructor as compile-time constants. 
+The key issue is whether one treats the formal parameters of a constructor as compile-time constants.
 
 If a constant constructor is invoked from a constant object expression, the actual arguments will be required to be compile-time constants. Therefore, if we were assured that constant constructors were always invoked from constant object expressions, we could assume that the formal parameters of a constructor were compile-time constants.
 
@@ -1579,7 +1579,7 @@ Nevertheless, the use of the formal parameters of a constant constructor within
 \CLASS{} C \{
   \FINAL{} x; \FINAL{} y; \FINAL{} z;
   \CONST{} C(p, q): x = q, y = p + 100, z = p + q;
-  % what about 
+  % what about
  %  \CONST{} C(p, q): x = q, y = p + 100, z = p + 'foo';
  % perhaps moot. Current spec says that would be ok; type checker can worry, as can execution, which is at compile time anyway
 \}
@@ -1627,15 +1627,15 @@ The effect of a static method declaration in class $C$ is to add an instance met
 \rationale{
 Inheritance of static methods has little utility in Dart. Static methods cannot be overridden. Any required static function can be obtained from its declaring library, and there is no need to bring it into scope via inheritance. Experience shows that developers are confused by the idea of inherited methods that are not instance methods.
 
-Of course, the entire notion of static methods is debatable, but it is retained here because so many programmers are familiar with it. Dart static methods may be seen as functions of the enclosing library. 
+Of course, the entire notion of static methods is debatable, but it is retained here because so many programmers are familiar with it. Dart static methods may be seen as functions of the enclosing library.
 }
 
 \LMHash{}
-It is a static warning if a class $C$ declares a static method named $n$ and has a setter named $n=$. 
+It is a static warning if a class $C$ declares a static method named $n$ and has a setter named $n=$.
 %It is a static warning if a class has a static method with the same name as a static member of one of its superclasses.
 
 %\rationale{
-%This last restriction makes classes more brittle with respect to changes in the class hierarchy. It stems from a general observation that shadowing of names in the same scope is questionable and should elicit a warning. 
+%This last restriction makes classes more brittle with respect to changes in the class hierarchy. It stems from a general observation that shadowing of names in the same scope is questionable and should elicit a warning.
 %}
 %\commentary{
 %There is no hiding of static methods, or of static variables.
@@ -1648,26 +1648,26 @@ It is a static warning if a class $C$ declares a static method named $n$ and has
 \LMHash{}
 {\em Static variables} are variables whose declarations are immediately contained within a class declaration and that are declared \STATIC{}. The static variables of a class $C$ are those static variables declared by $C$.
 
-%A static variable declaration  of one of the forms \code{\STATIC{} $T$ $v$;},  \code{\STATIC{} $T$ $v$ = $e$;} ,  \code{\STATIC{} \CONST{} $T$ $v$ = $e$;}  or \code{\STATIC{} \FINAL{} $T$ $v$ = $e$;} always induces an implicit static getter function (\ref{getters}) with signature 
+%A static variable declaration  of one of the forms \code{\STATIC{} $T$ $v$;},  \code{\STATIC{} $T$ $v$ = $e$;} ,  \code{\STATIC{} \CONST{} $T$ $v$ = $e$;}  or \code{\STATIC{} \FINAL{} $T$ $v$ = $e$;} always induces an implicit static getter function (\ref{getters}) with signature
 
 %\STATIC{} $T$ \GET{} $v$
 
 %whose invocation evaluates as described below (\ref{evaluationOfStaticVariableGetters}).%to the value stored in $v$.
 
 
-%A static variable declaration  of one of the forms \code{\STATIC{} \VAR{} $v$;},  \code{\STATIC{} \VAR{} $v$ = $e$;} ,  \code{\STATIC{} \CONST{} $v$ = $e$;} or \code{\STATIC{} \FINAL{}  $v$ = $e$;}  always induces an implicit static getter function with signature 
+%A static variable declaration  of one of the forms \code{\STATIC{} \VAR{} $v$;},  \code{\STATIC{} \VAR{} $v$ = $e$;} ,  \code{\STATIC{} \CONST{} $v$ = $e$;} or \code{\STATIC{} \FINAL{}  $v$ = $e$;}  always induces an implicit static getter function with signature
 
 %\STATIC{} \GET{} $v$
 
 %whose  invocation evaluates as described below (\ref{evaluationOfStaticVariableGetters}).%to the value stored in $v$.
 
-%A non-final static variable declaration  of the form \code{\STATIC{} $T$ $v$;} or the form  \code{\STATIC{} $T$ $v$ = $e$;}   always induces an implicit static setter function (\ref{setters}) with signature 
+%A non-final static variable declaration  of the form \code{\STATIC{} $T$ $v$;} or the form  \code{\STATIC{} $T$ $v$ = $e$;}   always induces an implicit static setter function (\ref{setters}) with signature
 
 %\STATIC{} \VOID{} \SET{} $v=(T$ $x)$
 
 %whose execution sets the value of $v$ to the incoming argument $x$.
 
-%A static variable declaration  of the form \code{\STATIC{} \VAR{} $v$;} or the form  \code{\STATIC{} \VAR{} $v$ = $e$;}   always induces an implicit static setter function with signature 
+%A static variable declaration  of the form \code{\STATIC{} \VAR{} $v$;} or the form  \code{\STATIC{} \VAR{} $v$ = $e$;}   always induces an implicit static setter function with signature
 
 %\STATIC{} \SET{} $v=(x)$
 
@@ -1678,12 +1678,12 @@ It is a static warning if a class $C$ declares a static method named $n$ and has
 %\subsubsection{Evaluation of Implicit Static Variable Getters}
 %\LMLabel{evaluationOfStaticVariableGetters}
 
-%Let $d$ be the declaration of a static variable $v$. The implicit getter method of $v$ executes as follows: 
+%Let $d$ be the declaration of a static variable $v$. The implicit getter method of $v$ executes as follows:
 %\begin{itemize}
-%\item If $d$ is of one of the forms \code{\STATIC{} \VAR{} $v$ = $e$;} , \code{\STATIC{} $T$ $v$ = $e$; }, \code{\STATIC{} \FINAL{} $v$ = $e$; } or \code{\STATIC{} \FINAL{} $T$ $v$ = $e$;} and no value has yet been stored into $v$ then the initializer expression $e$ is evaluated. If, during the evaluation of $e$, the getter for $v$ is referenced, a \code{CyclicInitializationError} is thrown. If the evaluation succeeded yielding an object $o$, let $r = o$, otherwise let $r = \NULL{}$. In any case, $r$ is stored into $v$. The result of executing the getter is $r$. 
+%\item If $d$ is of one of the forms \code{\STATIC{} \VAR{} $v$ = $e$;} , \code{\STATIC{} $T$ $v$ = $e$; }, \code{\STATIC{} \FINAL{} $v$ = $e$; } or \code{\STATIC{} \FINAL{} $T$ $v$ = $e$;} and no value has yet been stored into $v$ then the initializer expression $e$ is evaluated. If, during the evaluation of $e$, the getter for $v$ is referenced, a \code{CyclicInitializationError} is thrown. If the evaluation succeeded yielding an object $o$, let $r = o$, otherwise let $r = \NULL{}$. In any case, $r$ is stored into $v$. The result of executing the getter is $r$.
 %\item  If $d$ is of one of the forms \code{\STATIC{} \CONST{} $v$ = $e$; } or \code{\STATIC{} \CONST{} $T$ $v$ = $e$;} the result of the getter is the value of the compile time constant $e$.
 %Otherwise
-%\item The result of executing the getter method is the value stored in $v$.  
+%\item The result of executing the getter method is the value stored in $v$.
 %\end{itemize}
 
 
@@ -1695,7 +1695,7 @@ It is a static warning if a class $C$ declares a static method named $n$ and has
 The superclass of a class $C$ that has a with clause \code{\WITH{} $M_1, \ldots, M_k$} and an extends clause \code{\EXTENDS{} S} is the application of mixin (\ref{mixins}) $M_k* \cdots * M_1$  to S.  If no \WITH{} clause is specified then  the \EXTENDS{} clause of a class $C$ specifies its superclass. If no \EXTENDS{} clause is specified, then either:
 \begin{itemize}
 \item $C$ is \code{Object}, which has no superclass. OR
-\item Class $C$ is  deemed to have an \EXTENDS{} clause of the form \code{\EXTENDS{} Object}, and the rules above apply. 
+\item Class $C$ is  deemed to have an \EXTENDS{} clause of the form \code{\EXTENDS{} Object}, and the rules above apply.
 \end{itemize}
 
 \LMHash{}
@@ -1710,15 +1710,15 @@ It is a compile-time error to specify an \EXTENDS{} clause for class \code{Objec
 %The superclass clause of a class C is processed within the enclosing scope of the static scope of C.
 %\commentary{
 %This means that in a generic class, the type parameters of the generic are available in the superclass clause.
-%} 
+%}
 
 \LMHash{}
 The scope of the \EXTENDS{} and \WITH{} clauses of a class $C$ is the type-parameter scope of $C$.
 
 \LMHash{}
-%It is a compile-time error if  the \EXTENDS{} clause of a class $C$ includes a type expression that does not denote a class available in the lexical scope of $C$. 
+%It is a compile-time error if  the \EXTENDS{} clause of a class $C$ includes a type expression that does not denote a class available in the lexical scope of $C$.
 It is a compile-time error if  the \EXTENDS{} clause of a class $C$ specifies an enumerated type (\ref{enums}), a malformed  type or a deferred type (\ref{staticTypes}) as a superclass.
-% too strict? Do we e want extends List<Undeclared> to work as List<dynamic>? 
+% too strict? Do we e want extends List<Undeclared> to work as List<dynamic>?
 
 \commentary{ The type parameters of a generic class are available in the lexical scope of the superclass clause, potentially shadowing classes in the surrounding scope. The following code is therefore illegal and should cause a compile-time error:
 }
@@ -1727,7 +1727,7 @@ It is a compile-time error if  the \EXTENDS{} clause of a class $C$ specifies an
 class T \{\}
 
 /* Compilation error: Attempt to subclass a type parameter */
-class G$<$T$>$ extends T \{\} 
+class G$<$T$>$ extends T \{\}
 
 \end{dartCode}
 
@@ -1735,33 +1735,33 @@ class G$<$T$>$ extends T \{\}
 \LMHash{}
 A class $S$ is {\em a superclass} of a class $C$ iff either:
 \begin{itemize}
-\item $S$ is the superclass of $C$, or 
-\item $S$ is a superclass of a class $S^{\prime}$ and $S^{\prime}$ is a superclass of $C$. 
+\item $S$ is the superclass of $C$, or
+\item $S$ is a superclass of a class $S^{\prime}$ and $S^{\prime}$ is a superclass of $C$.
 \end{itemize}
 
 \LMHash{}
 It is a compile-time error if a class $C$ is a superclass of itself.
 
 
-    
- 
+
+
  \subsubsection{Inheritance and Overriding}
  \LMLabel{inheritanceAndOverriding}
 
 
-%A class $C$  {\em inherits} any accessible instance members of its superclass that are not overridden by members declared in $C$. 
+%A class $C$  {\em inherits} any accessible instance members of its superclass that are not overridden by members declared in $C$.
 
 \LMHash{}
 Let $C$ be a class,  let $A$ be a superclass of $C$, and let  $S_1 \ldots S_k$ be superclasses of $C$ that are also subclasses of $A$. $C$ {\em inherits} all accessible instance  members of  $A$ that have not been overridden by a declaration in $C$ or in at least one of $S_1 \ldots S_k$.
 
 \rationale {
 It would be  more attractive to give a purely local definition of inheritance, that depended only on the members of the direct superclass $S$. However, a class $C$ can inherit a member $m$ that  is not a member of its superclass  $S$. This can occur when the member $m$ is private
-to the library $L_1$ of $C$, whereas $S$ comes from a different library $L_2$, but 
+to the library $L_1$ of $C$, whereas $S$ comes from a different library $L_2$, but
 the superclass chain of $S$ includes a class declared in $L_1$.
 }
 
 \LMHash{}
-A class may override instance members that would otherwise have been inherited from its superclass. 
+A class may override instance members that would otherwise have been inherited from its superclass.
 
 \LMHash{}
 Let $C = S_0$ be a class declared in library $L$, and let $\{S_1 \ldots S_k\}$ be the set of all superclasses of $C$, where $S_i$ is the superclass of $S_{i-1}$ for $i \in 1 .. k$. Let $C$ declare a member $m$, and let  $m^\prime$ be a member of $S_j, j  \in 1 .. k$,  that has the same name as $m$, such that $m^\prime$ is accessible to $L$.  Then $m$ overrides $m^\prime$ if $m^\prime$ is not already overridden by a member of at least one of $S_1 \ldots S_{j-1}$ and neither $m$ nor $m^\prime$ are fields.
@@ -1774,10 +1774,10 @@ Let $C = S_0$ be a class declared in library $L$, and let $\{S_1 \ldots S_k\}$ b
 }
 
 \LMHash{}
-Whether an override is legal or not is described elsewhere in this specification (see \ref{instanceMethods}, \ref{getters} and \ref{setters}). 
+Whether an override is legal or not is described elsewhere in this specification (see \ref{instanceMethods}, \ref{getters} and \ref{setters}).
 
 \commentary{For example getters may not legally override methods and vice versa. Setters never override methods or getters, and vice versa, because their names always differ.
-}  
+}
 
 \rationale{
 It is nevertheless convenient to define the override relation between members in this way, so that we can concisely describe the illegal cases.
@@ -1805,19 +1805,19 @@ For convenience, here is a summary of the relevant rules. Remember that this is
 \item \label{typeSigAssignable}
 If two members override each other, it is a static warning if their type signatures are not assignable to each other (\ref{instanceMethods}, \ref{getters}, \ref{setters}) (and  since these are function types, this means the same as "subtypes of each other").
 \item \label{requiredParams}
-If two members override each other, it is a static warning if the overriding member has more required parameters  than the overridden one (\ref{instanceMethods}). 
+If two members override each other, it is a static warning if the overriding member has more required parameters  than the overridden one (\ref{instanceMethods}).
 \item  \label{optionalPositionals}
 If two members override each other, it is a static warning if the overriding member has fewer  positional parameters than the overridden one (\ref{instanceMethods}).
 \item  \label{namedParams}
 If two members override each other, it is a static warning if the overriding member does not have all the named parameters that the overridden one has (\ref{instanceMethods}).
 \item Setters, getters and operators never have optional parameters of any kind; it's a compile-time error (\ref{operators}, \ref{getters}, \ref{setters}).
 \item It is a compile-time error if a member has the same name as its enclosing class (\ref{classes}).
-\item A class has an implicit interface (\ref{classes}). 
+\item A class has an implicit interface (\ref{classes}).
 \item Superinterface members are not inherited by a class, but are inherited by its implicit interface. Interfaces have their own inheritance rules (\ref{interfaceInheritanceAndOverriding}).
 \item A member is abstract if it has no body and is not labeled \EXTERNAL{} (\ref{abstractInstanceMembers}, \ref{externalFunctions}).
 \item A class is abstract iff it is explicitly labeled \ABSTRACT{}.% or if it declares (not just inherits) an abstract member (\ref{classes}).
 \item It is a static warning if a concrete class has an abstract member (declared or inherited).
-\item It is a static warning and a dynamic error to call a non-factory constructor of an abstract class  (\ref{new}). 
+\item It is a static warning and a dynamic error to call a non-factory constructor of an abstract class  (\ref{new}).
 \item If a class defines an instance member named $m$, and any of its superinterfaces have a  member named $m$, the interface of the class overrides $m$.
 \item  An interface inherits all  members of its superinterfaces that are not overridden and not members of multiple superinterfaces.
 \item  If multiple superinterfaces of an interface define a member with the same name $m$, then at most one member is inherited. That member (if it exists) is the one whose type is a subtype of all the others. If there is no such member, then:
@@ -1826,7 +1826,7 @@ If two members override each other, it is a static warning if the overriding mem
   \item  If possible the interface gets a member named $m$ that has the minimum number of required parameters among all the members in the superinterfaces, the maximal number of    positionals, and the superset of named parameters.  The types of these are all \DYNAMIC{}. If this is impossible then no member $m$ appears in the interface.
   \end{itemize}  (\ref{interfaceInheritanceAndOverriding})
 \item  Rule \ref{typeSigAssignable} applies to interfaces as well as classes  (\ref{interfaceInheritanceAndOverriding}).
-\item  It is a static warning if a concrete class does not have an implementation for a  method in any of its superinterfaces  unless it has a \cd{noSuchMethod} method (\ref{superinterfaces}). 
+\item  It is a static warning if a concrete class does not have an implementation for a  method in any of its superinterfaces  unless it has a \cd{noSuchMethod} method (\ref{superinterfaces}).
 \item The identifier of a named constructor cannot be the same as the name of a member declared (as opposed to inherited) in the same class (\ref{constructors}).
 \end{enumerate}
 }
@@ -1856,7 +1856,7 @@ It is a compile-time error if  the \IMPLEMENTS{}  clause of a class $C$ specifie
 It is a compile-time error if the superclass of a class $C$ is specified as a superinterface of $C$.
 
 \rationale{
-One might argue that it is harmless to repeat a type in the superinterface list, so why make it an error? The issue is not so much that the situation described in program source is erroneous, but that it is pointless. As such, it is an indication that the programmer may very well have meant to say something else - and that is a mistake that should be called to her or his attention.  Nevertheless, we could simply issue a warning; and perhaps we should and will. That said, problems like these are local and easily corrected on the spot, so we feel justified in taking a harder line. 
+One might argue that it is harmless to repeat a type in the superinterface list, so why make it an error? The issue is not so much that the situation described in program source is erroneous, but that it is pointless. As such, it is an indication that the programmer may very well have meant to say something else - and that is a mistake that should be called to her or his attention.  Nevertheless, we could simply issue a warning; and perhaps we should and will. That said, problems like these are local and easily corrected on the spot, so we feel justified in taking a harder line.
 }
 
 \LMHash{}
@@ -1864,7 +1864,7 @@ It is a compile-time error if the interface of a class $C$ is a superinterface o
 
 \LMHash{}
 Let $C$ be a concrete class that does not have a \code{noSuchMethod()} method distinct from the one declared in class \cd{Object}.
-It is a static warning if the implicit interface of  $C$ includes an instance member $m$ of type $F$ and $C$ does not declare or inherit a corresponding non-abstract instance member $m$ of type $F'$ such that $F' <: F$. 
+It is a static warning if the implicit interface of  $C$ includes an instance member $m$ of type $F$ and $C$ does not declare or inherit a corresponding non-abstract instance member $m$ of type $F'$ such that $F' <: F$.
 
 \commentary{A class does not inherit members from its superinterfaces. However, its implicit interface does.
 }
@@ -1877,7 +1877,7 @@ We also disable these warnings if a \code{noSuchMethod()} declaration is present
 
 
 \LMHash{}
-It is a static warning if the implicit interface of  a class $C$ includes an instance member $m$ of type $F$ and $C$ declares or inherits a corresponding instance member $m$ of type $F'$ if  $F'$ is not a subtype of $F$. 
+It is a static warning if the implicit interface of  a class $C$ includes an instance member $m$ of type $F$ and $C$ declares or inherits a corresponding instance member $m$ of type $F'$ if  $F'$ is not a subtype of $F$.
 
 \rationale{
 However, if a class does explicitly declare a member that conflicts with its superinterface, this always yields a static warning.
@@ -1885,12 +1885,12 @@ However, if a class does explicitly declare a member that conflicts with its sup
 }
 %It is a static warning if an imported superinterface of a class $C$ declares private members.
 
-% Should we ignore unimplemented private members? 
+% Should we ignore unimplemented private members?
 
 %\rationale{This last rule is problematic. As code evolves in one library ($L_1$) it may add private members to a class $I_1$ implemented or inherited in another  library $L_2$ breaking $L_1$.  This is a direct result of coupling an interface based type system with library based privacy.  We are considering alternative semantics that might help resolve this issue.
 %}
 
-%\commentary{However, it is perfectly acceptable if a type mentioned in the implements clause is mentioned as a superinterface in an interface injection clause. 
+%\commentary{However, it is perfectly acceptable if a type mentioned in the implements clause is mentioned as a superinterface in an interface injection clause.
 %}
 
 %\rationale{We disallow repetition of a type in a given implements clause, as that is a localized mistake. However, separate clauses (that is the original class and various injections) may evolve separately over time, and we don't want to cause breakage. For example
@@ -1920,7 +1920,7 @@ An {\em interface} defines how one may interact with an object. An interface has
 \LMLabel{interfaceSuperinterfaces}
 
 \LMHash{}
-An interface has a set of direct superinterfaces. 
+An interface has a set of direct superinterfaces.
 
 \LMHash{}
 An interface $J$ is a superinterface of an interface $I$ iff either $J$ is a direct superinterface of $I$ or $J$ is a superinterface of a direct superinterface of $I$.
@@ -1934,8 +1934,8 @@ An interface $J$ is a superinterface of an interface $I$ iff either $J$ is a dir
 \LMHash{}
 Let $J$ be an interface and $K$ be a library. We define $inherited(J, K)$  to be the set of members $m$ such that   all of the following hold:
 \begin{itemize}
-\item $m$ is accessible to $K$ and 
-\item $A$ is a direct superinterface of $J$ and either 
+\item $m$ is accessible to $K$ and
+\item $A$ is a direct superinterface of $J$ and either
   \begin{itemize}
   \item $A$ declares a member $m$  or
   \item $m$ is a member of $inherited(A, K)$.
@@ -1949,17 +1949,17 @@ Furthermore, we define $overrides(J, K)$  to be the set of members $m^\prime$ su
 \item $J$ is the implicit interface of a class $C$.
 \item  $C$ declares a member $m$.
 \item $m^\prime$ has the same name as $m$.
-\item $m^\prime$ is accessible to $K$.  
+\item $m^\prime$ is accessible to $K$.
 \item $A$ is a direct superinterface of $J$ and either
   \begin{itemize}
-  \item $A$ declares a member $m^\prime$ or 
+  \item $A$ declares a member $m^\prime$ or
   \item $m^\prime$ is a member of $inherited(A, K)$.
   \end{itemize}
 \end{itemize}
 
 
 \LMHash{}
-Let $I$ be the implicit interface of a class $C$ declared in library $L$.  $I$ {\em inherits} all members of $inherited(I, L)$ and $I$ {\em overrides} $m^\prime$ if  $m^\prime \in overrides(I, L)$. 
+Let $I$ be the implicit interface of a class $C$ declared in library $L$.  $I$ {\em inherits} all members of $inherited(I, L)$ and $I$ {\em overrides} $m^\prime$ if  $m^\prime \in overrides(I, L)$.
 
 \LMHash{}
 All the static warnings pertaining to the overriding of instance members given in section \ref{classes} above hold for overriding between interfaces as well.
@@ -1969,36 +1969,36 @@ It is a static warning if $m$ is a method and $m^\prime$ is a getter, or if $m$
 
 
 
-%Let $I = S_0$ be the implicit interface of a class $C$ declared in library $L$, and let $\{S_1 \ldots S_k\}$ be the set of all superinterfaces of $I$. 
+%Let $I = S_0$ be the implicit interface of a class $C$ declared in library $L$, and let $\{S_1 \ldots S_k\}$ be the set of all superinterfaces of $I$.
 
-%Let $I$ be the implicit interface of a class $C$.  $I$ inherits any instance members of its superinterfaces that are not overridden by members declared in $C$. 
+%Let $I$ be the implicit interface of a class $C$.  $I$ inherits any instance members of its superinterfaces that are not overridden by members declared in $C$.
 
 % tighten definition? do we need chain as for classes?  Definition for interface override?
 
 \LMHash{}
-However, if the above rules would cause multiple members $m_1, \ldots,  m_k$ with the same name $n$ to be inherited (because identically named members existed in several superinterfaces) then at most one member is inherited. 
+However, if the above rules would cause multiple members $m_1, \ldots,  m_k$ with the same name $n$ to be inherited (because identically named members existed in several superinterfaces) then at most one member is inherited.
 
 \LMHash{}
 If some but not all of the $m_i, 1 \le i \le k$ are getters none of the $m_i$ are inherited, and a static warning is issued.
 
 \LMHash{}
 Otherwise, if the static types $T_1, \ldots,  T_k$ of the members $m_1, \ldots,  m_k$  are not identical, then there must be a member $m_x$ such that $T_x <: T_i, 1 \le x \le k$ for all  $i  \in 1..k$, or a static type warning occurs. The member that is inherited  is $m_x$, if it exists; otherwise:
- let $numberOfPositionals(f)$ denote the number of positional parameters of a function $f$, and let $numberOfRequiredParams(f)$ denote the number of required parameters of a function $f$. Furthermore, let $s$ denote the set of all named parameters of the $m_1, \ldots,  m_k$.  Then let 
+ let $numberOfPositionals(f)$ denote the number of positional parameters of a function $f$, and let $numberOfRequiredParams(f)$ denote the number of required parameters of a function $f$. Furthermore, let $s$ denote the set of all named parameters of the $m_1, \ldots,  m_k$.  Then let
 
 $h = max(numberOfPositionals(m_i)), $
 
-$r = min(numberOfRequiredParams(m_i)), i \in 1..k$. 
+$r = min(numberOfRequiredParams(m_i)), i \in 1..k$.
 
 \LMHash{}
-Then $I$ has a method named $n$, with $r$ required parameters of type \DYNAMIC{}, $h$  positional parameters of type \DYNAMIC{}, named parameters $s$ of type  \DYNAMIC{} and  return type  \DYNAMIC{}.  
+Then $I$ has a method named $n$, with $r$ required parameters of type \DYNAMIC{}, $h$  positional parameters of type \DYNAMIC{}, named parameters $s$ of type  \DYNAMIC{} and  return type  \DYNAMIC{}.
 
 
 
-\commentary{The only situation where the runtime would be concerned with this would be during reflection, if a mirror attempted to obtain the signature of an interface member. 
+\commentary{The only situation where the runtime would be concerned with this would be during reflection, if a mirror attempted to obtain the signature of an interface member.
 }
 
 \rationale{
-The current solution is a tad complex, but is robust in the face of type annotation changes.  Alternatives: (a) No member is inherited in case of conflict. (b) The first m is selected (based on order of superinterface list) (c) Inherited member chosen at random. 
+The current solution is a tad complex, but is robust in the face of type annotation changes.  Alternatives: (a) No member is inherited in case of conflict. (b) The first m is selected (based on order of superinterface list) (c) Inherited member chosen at random.
 
 (a) means that the presence of an inherited member of an interface varies depending on type signatures.  (b) is sensitive to irrelevant details of the declaration and (c) is liable to give unpredictable results between implementations or even between different compilation sessions.
 }
@@ -2006,14 +2006,14 @@ The current solution is a tad complex, but is robust in the face of type annotat
 % Need warnings if overrider conflicts with overriddee either because signatures are incompatible or because done is a method and one is a getter or setter.
 
 \section{Mixins}
-\LMLabel{mixins} 
+\LMLabel{mixins}
 
 
 \LMHash{}
-A mixin describes the difference between a class and its superclass. A mixin is always derived from an existing class declaration. 
+A mixin describes the difference between a class and its superclass. A mixin is always derived from an existing class declaration.
 
 \LMHash{}
-It is a compile-time error if a declared or derived mixin explicitly declares a constructor. 
+It is a compile-time error if a declared or derived mixin explicitly declares a constructor which is not a factory constructor.
 
 \rationale{
 This restriction is temporary.  We expect to remove it in later versions of Dart.
@@ -2031,25 +2031,25 @@ A mixin may be applied to a superclass, yielding a new class. Mixin application
 \begin{grammar}
 {\bf  mixinApplicationClass:}
 	identifier typeParameters? `='  mixinApplication `{\escapegrammar ;}' .
-	
+
 {\bf mixinApplication:}
-     type mixins interfaces? 
+     type mixins interfaces?
     .
 \end{grammar}
 
 \LMHash{}
-A  mixin application of the form  \code{$S$ \WITH{} $M$;} defines a class  $C$ with superclass  $S$. 
+A  mixin application of the form  \code{$S$ \WITH{} $M$;} defines a class  $C$ with superclass  $S$.
 
 \LMHash{}
-A  mixin application of the form  \code{$S$ \WITH{} $M_1, \ldots, M_k$;} defines a class  $C$ whose superclass is the application of the mixin composition (\ref{mixinComposition}) $M_{k-1} * \ldots * M_1$ to $S$. 
+A  mixin application of the form  \code{$S$ \WITH{} $M_1, \ldots, M_k$;} defines a class  $C$ whose superclass is the application of the mixin composition (\ref{mixinComposition}) $M_{k-1} * \ldots * M_1$ to $S$.
 
 \LMHash{}
-In both cases above, $C$ declares the same instance members as $M$ (respectively, $M_k$). If any of the instance fields of $M$ (respectively, $M_k$) have initializers, they are executed in the scope of $M$ (respectively, $M_k$) to initialize the corresponding fields of $C$. 
+In both cases above, $C$ declares the same instance members as $M$ (respectively, $M_k$). If any of the instance fields of $M$ (respectively, $M_k$) have initializers, they are executed in the scope of $M$ (respectively, $M_k$) to initialize the corresponding fields of $C$.
 
 \LMHash{}
 Let $L_M$ be the library in which $M$ is declared.
 For each generative constructor named $q_i(T_{i1}$ $ a_{i1}, \ldots , T_{ik_i}$ $ a_{ik_i}), i \in 1..n$ of $S$ that is accessible to $L_M$, $C$ has an implicitly declared constructor named
-$q'_i = [C/S]q_i$ of the form 
+$q'_i = [C/S]q_i$ of the form
 
 $q'_i(a_{i1}, \ldots , a_{ik_i}):\SUPER(a_{i1}, \ldots , a_{ik_i});$.
 
@@ -2059,7 +2059,7 @@ $q'_i(a_{i1}, \ldots , a_{ik_i}):\SUPER(a_{i1}, \ldots , a_{ik_i});$.
 If the mixin application declares support for interfaces, the resulting class implements those interfaces.
 
 \LMHash{}
-It is a compile-time error if $S$ is an enumerated type (\ref{enums}) or a malformed type. It is a compile-time error if $M$ (respectively, any of $M_1, \ldots, M_k$) is an enumerated type (\ref{enums}) or a malformed type. It is a compile time error if a well formed mixin cannot be derived from $M$ (respectively, from each of $M_1, \ldots, M_k$). 
+It is a compile-time error if $S$ is an enumerated type (\ref{enums}) or a malformed type. It is a compile-time error if $M$ (respectively, any of $M_1, \ldots, M_k$) is an enumerated type (\ref{enums}) or a malformed type. It is a compile time error if a well formed mixin cannot be derived from $M$ (respectively, from each of $M_1, \ldots, M_k$).
 
 \LMHash{}
 Let $K$ be a class declaration  with the same constructors, superclass and interfaces as $C$,  and the instance members declared by $M$ (respectively $M_1, \ldots, M_k$). It is a static warning if the declaration of $K$ would cause a static warning.  It is a compile-time error if the declaration of $K$ would cause a compile-time error.
@@ -2070,15 +2070,15 @@ If, for example, $M$ declares an instance member $im$ whose type is at odds with
 }
 
 \LMHash{}
-The effect of a class definition of the form \code{\CLASS{} $C$ = $M$; } or the form 
+The effect of a class definition of the form \code{\CLASS{} $C$ = $M$; } or the form
  \code{\CLASS{} $C<T_1, \ldots, T_n>$ = $M$; } in library $L$  is to introduce the name $C$ into the scope of $L$, bound to the class (\ref{classes}) defined by the mixin application $M$. The name of the class is also set to $C$. Iff the  class is prefixed by the built-in identifier \ABSTRACT{}, the class being defined is an abstract class.
- 
+
  Let $M_A$ be a mixin derived from a class $M$ with direct superclass $S_{static}$.
 
 Let $A$ be an application of $M_A$. It is a static warning if the superclass of $A$ is not a subtype of $S_{static}$.
 
 Let $C$ be a class declaration that includes $M_A$ in a with clause. It is a static warning if $C$ does not implement, directly or indirectly, all the direct superinterfaces of $M$.
- 
+
 
 \subsection{Mixin Composition}
 \LMLabel{mixinComposition}
@@ -2088,25 +2088,25 @@ Dart does not directly support mixin composition, but the concept is useful when
 }
 
 \LMHash{}
-The {\em composition of two mixins}, $M_1<T_1 \ldots T_{k_{M_1}}>$ and $M_2<U_1  \ldots U_{k_{M_2}}>$, written $M_1<T_1 \ldots T_{k_{M_1}}> * M_2<U_1  \ldots U_{k_{M_2}}>$ defines an anonymous mixin such that for any class $S<V_1 \ldots V_{k_S}>$, the application of 
+The {\em composition of two mixins}, $M_1<T_1 \ldots T_{k_{M_1}}>$ and $M_2<U_1  \ldots U_{k_{M_2}}>$, written $M_1<T_1 \ldots T_{k_{M_1}}> * M_2<U_1  \ldots U_{k_{M_2}}>$ defines an anonymous mixin such that for any class $S<V_1 \ldots V_{k_S}>$, the application of
 
-$M_1<T_1 \ldots T_{k_{M_1}}> * M_2<U_1  \ldots U_{k_{M_2}}>$  
+$M_1<T_1 \ldots T_{k_{M_1}}> * M_2<U_1  \ldots U_{k_{M_2}}>$
 
-to $S<V_1 \ldots V_{k_S}>$ is equivalent to 
+to $S<V_1 \ldots V_{k_S}>$ is equivalent to
 
 \begin{dartCode}
 \ABSTRACT{} \CLASS{} $Id_1<T_1  \ldots T_{k_{M_1}}, U_1  \ldots U_{k_{M_2}}, V_1  \ldots V_{k_S}> = $
       $Id_2<U_1  \ldots U_{k_{M_2}}, V_1  \ldots V_{k_S}>$ \WITH{} $M_1 <T_1  \ldots T_{k_{M_1}}>$;
 \end{dartCode}
 
-where $Id_2$ denotes 
+where $Id_2$ denotes
 
 \begin{dartCode}
 \ABSTRACT{}  \CLASS{} $Id_2<U_1 \ldots U_{k_{M_2}}, V_1 \ldots V_{k_S}> =$
-                         $S<V_1 \ldots V_{k_S}>$ \WITH{} $M_2<U_1  \ldots U_{k_{M_2}}>$; 
+                         $S<V_1 \ldots V_{k_S}>$ \WITH{} $M_2<U_1  \ldots U_{k_{M_2}}>$;
 \end{dartCode}
 
-and $Id_1$ and $Id_2$ are unique identifiers that do not exist anywhere in the program. 
+and $Id_1$ and $Id_2$ are unique identifiers that do not exist anywhere in the program.
 
 \rationale{
 The classes produced by mixin composition are regarded as abstract because they cannot be instantiated independently. They are only introduced as anonymous superclasses of ordinary class declarations and mixin applications. Consequently, no warning is given if a mixin composition includes abstract members, or incompletely implements an interface.
@@ -2157,8 +2157,8 @@ It is also a compile-time error to subclass, mix-in or implement an enum or to e
 \LMLabel{generics}
 
 \LMHash{}
-A class declaration (\ref{classes}) or type alias (\ref{typedef}) 
-$G$ may be {\em generic}, that is, $G$ may have formal type parameters declared. A generic declaration induces a family of declarations, one for each set of actual type parameters provided in the program. 
+A class declaration (\ref{classes}) or type alias (\ref{typedef})
+$G$ may be {\em generic}, that is, $G$ may have formal type parameters declared. A generic declaration induces a family of declarations, one for each set of actual type parameters provided in the program.
 
 \begin{grammar}
 {\bf typeParameter:}
@@ -2177,7 +2177,7 @@ Type parameters are declared in the type-parameter scope of a class.
 The type parameters of a generic $G$ are in scope in the bounds of all of the type parameters of $G$. The type parameters of a generic class declaration $G$ are also in scope in the \EXTENDS{} and \IMPLEMENTS{} clauses of $G$ (if these exist) and in the body of $G$.   However, a type parameter is considered to be a malformed type when referenced by a static member.
 
 \rationale{
-The restriction is necessary since a type variable has no meaning in the context of a static member, because statics are shared among all instantiations of a generic. However, a type variable may be referenced from an instance initializer, even though \THIS{} is not available. 
+The restriction is necessary since a type variable has no meaning in the context of a static member, because statics are shared among all instantiations of a generic. However, a type variable may be referenced from an instance initializer, even though \THIS{} is not available.
 }
 
 \commentary{
@@ -2206,7 +2206,7 @@ Even where type parameters are in scope there are numerous restrictions at this
 The normative versions of these  are given in the appropriate sections of this specification. Some of these restrictions may be lifted in the future.
 }
 
-%The {\em induced type set}, $S$, of a parameterized type $T$ is the set consisting of 
+%The {\em induced type set}, $S$, of a parameterized type $T$ is the set consisting of
 %\begin{itemize}
 %\item The supertypes of any type in $S$.
 %\item The type arguments of any parameterized type in $S$.
@@ -2264,13 +2264,13 @@ The normative versions of these  are given in the appropriate sections of this s
     %.
 %\end{grammar}
 
-%\rationale{Since subinterface relations can be tested dynamically via \IS{}, interface injection is not just a directive to the static checker. The dynamic relations implied must  hold regardless of whether a static typecheck has succeeded, or has been performed at all. This makes sense from the perspective of preserving programmer intent. The injection describes a nominal type relation that the programmer wishes to hold. Just as a supertype mentioned within a class declaration is considered a supertype even though type errors might arise among (say) overridden and overriding methods, so it must be that the relation implied by an injection holds regardless of type errors. 
+%\rationale{Since subinterface relations can be tested dynamically via \IS{}, interface injection is not just a directive to the static checker. The dynamic relations implied must  hold regardless of whether a static typecheck has succeeded, or has been performed at all. This makes sense from the perspective of preserving programmer intent. The injection describes a nominal type relation that the programmer wishes to hold. Just as a supertype mentioned within a class declaration is considered a supertype even though type errors might arise among (say) overridden and overriding methods, so it must be that the relation implied by an injection holds regardless of type errors.
 %In addition, this decision helps to produce meaningful and localized error messages. Any errors are reported at the point of injection rather than at program points that rely on the relation (a well known problem with structural subtyping in OO systems).
 %}
 
 %\Q{When does an interface injection take effect? When the containing library is loaded?
-%What is the scope of such a declaration? Is it global, or only in the scope of the containing library? The scope of such a declaration is global. 
-%An injection must be at top level. Who has the right to inject an interface $I$ into another class $C$? Anybody? But since this affects dynamic behavior, is this a weird security issue? 
+%What is the scope of such a declaration? Is it global, or only in the scope of the containing library? The scope of such a declaration is global.
+%An injection must be at top level. Who has the right to inject an interface $I$ into another class $C$? Anybody? But since this affects dynamic behavior, is this a weird security issue?
 %The current theory is that there is no security within an isolate, and one can never refer to a type from another isolate, so supposedly not an issue. This assumption (no mutually suspicious code in the same isolate) is suspect but it seems there is nothing to be done at this point.
 %If libs are first class, they get created dynamically in order, and new libs might modify the type relations among other libs types - but then it is clear when that happened and order is ok.
 %}
@@ -2282,7 +2282,7 @@ The normative versions of these  are given in the appropriate sections of this s
 \LMLabel{metadata}
 
 \LMHash{}
-Dart supports metadata which is used to attach user defined annotations to program structures.  
+Dart supports metadata which is used to attach user defined annotations to program structures.
 
 \begin{grammar}
 {\bf metadata:}
@@ -2316,7 +2316,7 @@ It is possible to associate metadata with constructs that may not be accessible
 Metadata can appear before a library, part header, class, typedef, type parameter, constructor, factory, function, field, parameter, or variable declaration and before an import, export or part directive.
 
 \LMHash{}
-The constant expression given in an annotation  is type checked and evaluated in the scope surrounding the declaration being annotated.  
+The constant expression given in an annotation  is type checked and evaluated in the scope surrounding the declaration being annotated.
 
 
 \section{Expressions}
@@ -2330,19 +2330,19 @@ An {\em expression} is a fragment of Dart code that can be evaluated at run time
 
 {\bf expression:}assignableExpression assignmentOperator expression;
        conditionalExpression cascadeSection*;
-       throwExpression     
+       throwExpression
     .
-     
-    
+
+
 {\bf expressionWithoutCascade:}assignableExpression assignmentOperator expressionWithoutCascade;
       conditionalExpression;
-      throwExpressionWithoutCascade    
+      throwExpressionWithoutCascade
     .
 
 {\bf expressionList:}
       expression (`,' expression)* %should these be top level expressions?
     .
-\end{grammar}    
+\end{grammar}
 
 \begin{grammar}
 {\bf primary:}thisExpression;
@@ -2355,8 +2355,8 @@ An {\em expression} is a fragment of Dart code that can be evaluated at run time
       constObjectExpression;
       `(' expression `)'
     .
-    
-\end{grammar}   
+
+\end{grammar}
 
 \LMHash{}
 An expression $e$ may always be enclosed in parentheses, but this never has any semantic effect on $e$.
@@ -2367,7 +2367,7 @@ Sadly, it may have an effect on the surrounding expression. Given a class $C$ wi
 
  \subsubsection{Object Identity}
  \LMLabel{objectIdentity}
- 
+
 \LMHash{}
 The predefined Dart function \cd{identical()} is defined such that \code{identical($c_1$, $c_2$)} iff:
  \begin{itemize}
@@ -2387,9 +2387,9 @@ The predefined Dart function \cd{identical()} is defined such that \code{identic
  \item $c_1$ and $c_2$ are constant objects of the same class $C$ and each member field of $c_1$ is identical to the corresponding field of $c_2$. OR
 \item $c_1$ and $c_2$ are the same object.
 \end{itemize}
-    
+
 \commentary{
-The definition of \cd{identity} for doubles differs from that of equality in that a NaN is identical to itself, and that negative and positive zero are distinct.  
+The definition of \cd{identity} for doubles differs from that of equality in that a NaN is identical to itself, and that negative and positive zero are distinct.
 }
 
 \rationale{
@@ -2399,13 +2399,13 @@ The definition of identity is not constrained in the same way. Instead, it assum
 
 The rules for identity make it impossible for a Dart programmer to observe whether a boolean or numerical value is boxed or unboxed.
 }
-    
-    
+
+
 \subsection{Constants}
 \LMLabel{constants}
 
 \LMHash{}
-A {\em constant expression} is an expression whose value can never change, and that can be evaluated entirely at compile time. 
+A {\em constant expression} is an expression whose value can never change, and that can be evaluated entirely at compile time.
 
 \LMHash{}
 A constant expression is one of the following:
@@ -2416,14 +2416,14 @@ A constant expression is one of the following:
 \rationale{It would be tempting to allow string interpolation where the interpolated value is any compile-time constant.  However, this would require running the \code{toString()} method for constant objects, which could contain arbitrary code.}
 \item A literal symbol (\ref{symbols}).
 \item \NULL{} (\ref{null}).
-\item A qualified reference to a static constant variable (\ref{variables}) that is not qualified by a deferred prefix. 
+\item A qualified reference to a static constant variable (\ref{variables}) that is not qualified by a deferred prefix.
 \commentary {For example, If class C declares a constant static variable v, C.v is a constant. The same is true if C is accessed via a prefix p; p.C.v is a constant  unless p is a deferred prefix.
 }
-\item An identifier expression that denotes a constant variable. 
-\item A simple or qualified identifier denoting a class or type alias that is not qualified by a deferred prefix. 
+\item An identifier expression that denotes a constant variable.
+\item A simple or qualified identifier denoting a class or type alias that is not qualified by a deferred prefix.
 \commentary {For example, If C is a class or typedef, C is a constant, and if C is imported with a prefix p, p.C is a constant unless p is a deferred prefix.
 }
-\item A constant constructor invocation (\ref{const}) that is not qualified by a deferred prefix.  
+\item A constant constructor invocation (\ref{const}) that is not qualified by a deferred prefix.
 \item A constant list literal (\ref{lists}).
 \item A constant map literal (\ref{maps}).
 \item A simple or qualified identifier denoting a top-level function (\ref{functions}) or a static method (\ref{staticMethods}) that is not qualified by a deferred prefix.
@@ -2444,7 +2444,7 @@ A constant expression is one of the following:
 % designed so constants do not depend on check diode being on or not.
 
 \LMHash{}
-It is a compile-time error if an expression is required to be a constant expression but its evaluation  would raise an exception. 
+It is a compile-time error if an expression is required to be a constant expression but its evaluation  would raise an exception.
 
 % so, checked mode? analyzers? editor/development compilers?
 \commentary{
@@ -2465,15 +2465,15 @@ On the other hand, since implementations are free to compile code late, some com
     \IF{} (z) \{\RETURN{} x; \}
     \ELSE{} \{ \RETURN{} 2;\}
   \}
-  
+
   m2() \{
     \IF{} (\TRUE{}) \{\RETURN{} y; \}
     \ELSE{} \{ \RETURN{} 3;\}
-  \}  
+  \}
 \}
 \end{dartCode}
 
-\commentary{An implementation is free to immediately issue a compilation error for  \code{x}, but it is not required to do so.  It could defer errors if it does not immediately compile the declarations that reference \code{x}. For example, it could delay giving a compilation error about the method \code{m1} until the first invocation of \code{m1}. However, it could not choose to execute \code{m1},  see that the branch that refers to \code{x} is not taken and return 2 successfully. 
+\commentary{An implementation is free to immediately issue a compilation error for  \code{x}, but it is not required to do so.  It could defer errors if it does not immediately compile the declarations that reference \code{x}. For example, it could delay giving a compilation error about the method \code{m1} until the first invocation of \code{m1}. However, it could not choose to execute \code{m1},  see that the branch that refers to \code{x} is not taken and return 2 successfully.
 
 The situation with respect to an invocation \code{m2} is different. Because \code{y} is not a compile-time constant (even though its value is), one need not give a compile-time error upon compiling \code{m2}. An implementation may run the code, which will cause  the getter for \code{y} to be invoked. At that point, the initialization of \code{y} must take place, which requires the initializer to be compiled, which will cause a compilation error.
 }
@@ -2481,11 +2481,19 @@ The situation with respect to an invocation \code{m2} is different. Because \cod
 \rationale{
 The treatment of \NULL{} merits some discussion. Consider \code{\NULL{} + 2}.  This expression always causes an error. We could have chosen not to treat it as a constant expression (and in general, not to allow \NULL{} as a subexpression of numeric or boolean constant expressions).  There are two arguments for including it:
 \begin{enumerate}
-\item It is constant. We can evaluate it at compile-time. 
+\item It is constant. We can evaluate it at compile-time.
 \item It seems more useful to give the error stemming from the evaluation explicitly.
 \end{enumerate}
 }
 
+\rationale {
+One might reasonably ask why $e_1? e_1: e_3$ and $e_1?? e_2$ have constant forms. For example, if $e_1$ is known statically, why do we need to test it?.
+The answer is that there are contexts where $e_1$ is a variable. In particular, constant constructor initializers such as

[floitsch, 2016/06/22 14:57:17]

This sentence feels incomplete.

+
+\code{\CONST{} C(foo) : \THIS.foo = foo ?? someDefaultValue;}
+}
+
+
 \LMHash{}
 It is a compile-time error if the value of a compile-time constant expression depends on itself.
 
@@ -2494,7 +2502,7 @@ As an example, consider:
 }
 
 \begin{dartCode}
-\CLASS{} CircularConsts\{ 
+\CLASS{} CircularConsts\{
 // Illegal program - mutually recursive compile-time constants
   \STATIC{} \CONST{} i = j; // a compile-time constant
   \STATIC{} \CONST{} j = i; // a compile-time constant
@@ -2529,13 +2537,13 @@ The reserved word \NULL{} denotes the {\em null object}.
 \end{grammar}
 
 \LMHash{}
-The null object is the sole instance of the built-in class \code{Null}. Attempting to instantiate \code{Null} causes a run-time error. It is a compile-time error for a class to attempt to extend, mix in or implement \code{Null}. 
+The null object is the sole instance of the built-in class \code{Null}. Attempting to instantiate \code{Null} causes a run-time error. It is a compile-time error for a class to attempt to extend, mix in or implement \code{Null}.
 Invoking a method on \NULL{}  yields a \code{NoSuchMethodError} unless the method is explicitly implemented by class \code{Null}.
 
 \LMHash{}
 The static type of \NULL{} is $\bot$.
 
-\rationale{The decision to use $\bot$ instead of \code{Null} allows \NULL{} to be be assigned everywhere without complaint by the static checker. 
+\rationale{The decision to use $\bot$ instead of \code{Null} allows \NULL{} to be be assigned everywhere without complaint by the static checker.
 }
 
 
@@ -2549,7 +2557,7 @@ A {\em numeric literal} is either a decimal or hexadecimal integer of arbitrary
 {\bf numericLiteral:}NUMBER;
       HEX\_NUMBER
     .
-    
+
   {\bf NUMBER:} DIGIT+ (`{\escapegrammar.}' DIGIT+)? EXPONENT?;
       {`\escapegrammar .}' DIGIT+ EXPONENT?
     .
@@ -2567,9 +2575,9 @@ A {\em numeric literal} is either a decimal or hexadecimal integer of arbitrary
       DIGIT
     .
  \end{grammar}
- 
+
 \LMHash{}
-If a numeric literal begins with the prefix `0x' or `0X', it denotes the hexadecimal integer represented by the part of the literal following `0x' (respectively `0X'). Otherwise, if the numeric literal does not include a decimal point  it denotes a decimal integer.  Otherwise, the numeric literal  denotes a 64 bit double precision floating point number as specified by the IEEE 754 standard. 
+If a numeric literal begins with the prefix `0x' or `0X', it denotes the hexadecimal integer represented by the part of the literal following `0x' (respectively `0X'). Otherwise, if the numeric literal does not include a decimal point  it denotes a decimal integer.  Otherwise, the numeric literal  denotes a 64 bit double precision floating point number as specified by the IEEE 754 standard.
 
 \LMHash{}
 In principle, the range of integers supported by a Dart implementations is unlimited. In practice, it is limited by available memory. Implementations may also be limited by other considerations.
@@ -2582,12 +2590,12 @@ For example, implementations may choose to limit the range to facilitate efficie
 It is a compile-time error for a class to attempt to extend, mix in or implement \code{int}. It is a compile-time error for a class to attempt to extend, mix in or implement \code{double}. It is a compile-time error for any type other than the types \code{int} and \code{double} to attempt to extend, mix in or implement \code{num}.
 
 \LMHash{}
-An {\em integer literal} is either a hexadecimal integer literal or a  decimal integer literal. Invoking the getter \code{runtimeType} on an integer literal returns the \code{Type} object that is the value of the expression \code{int}. The static type of an integer literal is \code{int}. 
+An {\em integer literal} is either a hexadecimal integer literal or a  decimal integer literal. Invoking the getter \code{runtimeType} on an integer literal returns the \code{Type} object that is the value of the expression \code{int}. The static type of an integer literal is \code{int}.
 
 \LMHash{}
 A {\em literal double} is a numeric literal that is not an integer literal. Invoking the getter \code{runtimeType} on a literal double returns the \code{Type} object that is the value of the expression \code{double}.
 The static type of a literal double is \code{double}.
-    
+
 \subsection{Booleans}
 \LMLabel{booleans}
 
@@ -2601,10 +2609,10 @@ The reserved words \TRUE{} and \FALSE{} denote objects that represent the boolea
 \end{grammar}
 
 \LMHash{}
-Both  \TRUE{} and \FALSE{} implement the built-in class \code{bool}.  It is a compile-time error for a class to attempt to extend, mix in or implement\code{ bool}. 
+Both  \TRUE{} and \FALSE{} implement the built-in class \code{bool}.  It is a compile-time error for a class to attempt to extend, mix in or implement\code{ bool}.
 
 \commentary{
-It follows that the two boolean literals are the only two instances of \code{bool}. 
+It follows that the two boolean literals are the only two instances of \code{bool}.
 }
 
 \LMHash{}
@@ -2625,21 +2633,21 @@ Invoking the getter \code{runtimeType} on a boolean literal returns the \code{Ty
 \end{dartCode}
 
 \rationale{
-Boolean conversion is used as part of control-flow constructs and boolean expressions.  Ideally, one would simply insist that control-flow decisions be based exclusively on booleans.  This is straightforward in a statically typed setting. In a dynamically typed language, it requires a dynamic check. Sophisticated virtual machines can minimize the penalty involved. Alas, Dart must be compiled into Javascript. Boolean conversion allows this to be done efficiently. 
+Boolean conversion is used as part of control-flow constructs and boolean expressions.  Ideally, one would simply insist that control-flow decisions be based exclusively on booleans.  This is straightforward in a statically typed setting. In a dynamically typed language, it requires a dynamic check. Sophisticated virtual machines can minimize the penalty involved. Alas, Dart must be compiled into Javascript. Boolean conversion allows this to be done efficiently.
 
 At the same time, this formulation differs radically from Javascript, where most numbers and objects are interpreted as \TRUE{}.  Dart's approach prevents usages such \code{\IF{} (a-b) ... ; }because it does not agree with the low level conventions whereby non-null objects or non-zero numbers are treated as \TRUE{}. Indeed, there is no way to derive \TRUE{} from a non-boolean object via boolean conversion, so this kind of low level hackery is nipped in the bud.
 
-Dart also avoids the strange behaviors that can arise due to the interaction of boolean conversion with autoboxing in Javascript. A notorious example is the situation where \FALSE{} can be interpreted as \TRUE{}. In Javascript, booleans are not objects, and instead are autoboxed into objects where ``needed''.  If \FALSE{} gets autoboxed into an object, that object can be coerced into \TRUE{} (as it is a non-null object). 
+Dart also avoids the strange behaviors that can arise due to the interaction of boolean conversion with autoboxing in Javascript. A notorious example is the situation where \FALSE{} can be interpreted as \TRUE{}. In Javascript, booleans are not objects, and instead are autoboxed into objects where ``needed''.  If \FALSE{} gets autoboxed into an object, that object can be coerced into \TRUE{} (as it is a non-null object).
 }
 
 \commentary{Because boolean conversion requires its parameter to be a boolean, any construct that makes use of boolean conversion will cause a dynamic type error in checked mode if the value to be converted is not a boolean.
  }
-    
+
 \subsection{Strings}
 \LMLabel{strings}
 
 \LMHash{}
-A {\em string} is a sequence of UTF-16 code units. 
+A {\em string} is a sequence of UTF-16 code units.
 
 \rationale{
 This decision was made for compatibility with web browsers and Javascript. Earlier versions of the specification required a string to be a sequence of valid Unicode code points.  Programmers should not depend on this distinction.
@@ -2651,7 +2659,7 @@ This decision was made for compatibility with web browsers and Javascript. Earli
 \end{grammar}
 
 \LMHash{}
-A string can be either a sequence of single line strings or a multiline string. 
+A string can be either a sequence of single line strings or a multiline string.
 
 \begin{grammar}
  {\bf singleLineString:}`{\escapegrammar \code{"}}' stringContentDQ* `{\escapegrammar \code{"}}';
@@ -2662,7 +2670,7 @@ A string can be either a sequence of single line strings or a multiline string.
 \end{grammar}
 
 \LMHash{}
-A single line string is delimited by either matching single quotes or matching double quotes.  
+A single line string is delimited by either matching single quotes or matching double quotes.
 
 \commentary{
 Hence, `abc' and ``abc'' are both legal strings, as are `He said ``To be or not to be'' did he not?'  and ``He said `To be or not to be' didn't he''. However  ``This ` is not a valid string, nor is `this''.
@@ -2672,8 +2680,8 @@ Hence, `abc' and ``abc'' are both legal strings, as are `He said ``To be or not
 }
 
 \LMHash{}
-Adjacent 
-%single line 
+Adjacent
+%single line
 strings are implicitly concatenated to form a single string literal.
 %, and so are adjacent multiline strings, but the two forms may not be mixed.
 
@@ -2684,7 +2692,7 @@ strings are implicitly concatenated to form a single string literal.
 print("A string" "and then another"); // prints: A stringand then another
 \end{dartCode}
 
-\rationale{Dart also supports the operator + for string concatenation. 
+\rationale{Dart also supports the operator + for string concatenation.
 
 The + operator on Strings requires a String argument. It does not coerce its argument into a string. This helps avoid puzzlers such as
 }
@@ -2725,8 +2733,8 @@ print("A simple sum: 2 + 2 =  \$\{2+2\}");
       `r' `{\escapegrammar \texttt{"""}}'  (\~{} `{\escapegrammar \texttt{"""}}')*   `{\escapegrammar \texttt{"""}}';
       `r' `{\escapegrammar \code{'}\code{'}\code{'}}' (\~{} `{\escapegrammar \code{'}\code{'}\code{'}}')* `{\escapegrammar \code{'}\code{'}\code{'}}'
     .
-    
-    
+
+
     {\bf ESCAPE\_SEQUENCE:} `$\backslash$ n';
     `$\backslash$ r';
    `$\backslash$ f';
@@ -2737,21 +2745,21 @@ print("A simple sum: 2 + 2 =  \$\{2+2\}");
    `$\backslash$ u' HEX\_DIGIT HEX\_DIGIT HEX\_DIGIT HEX\_DIGIT;
    `$\backslash$ u\{' HEX\_DIGIT\_SEQUENCE `\}'
   .
-  
+
 {\bf HEX\_DIGIT\_SEQUENCE:}
-     HEX\_DIGIT HEX\_DIGIT? HEX\_DIGIT? HEX\_DIGIT? HEX\_DIGIT? HEX\_DIGIT? 
+     HEX\_DIGIT HEX\_DIGIT? HEX\_DIGIT? HEX\_DIGIT? HEX\_DIGIT? HEX\_DIGIT?
     .
-   
+
 \end{grammar}
 
 \LMHash{}
 Multiline strings are delimited by either matching triples of single quotes or matching triples of double quotes. If the first line of a multiline string consists solely of the whitespace characters defined by the production {\em WHITESPACE}  \ref{lexicalRules}), possibly prefixed by $\backslash$, then that line is ignored, including the new line at its end.
 
- 
+
  \rationale{
  The idea is to ignore whitespace, where whitespace is defined as tabs, spaces and newlines. These can be represented directly, but since for most characters prefixing by backslash is an identity, we allow those forms as well.
  }
- 
+
  % could be clearer. Is the first line in  """\t
  %    """ ignored not. It depends if we mean whitespace before escapes are interpreted,
  % or after, or both.  See https://code.google.com/p/dart/issues/detail?id=23020
@@ -2765,7 +2773,7 @@ Strings support escape sequences for special characters. The escapes are:
 \item $\backslash$b for backspace, equivalent to $\backslash$x08.
 \item $\backslash$t for tab, equivalent to $\backslash$x09.
 \item $\backslash$v for vertical tab, equivalent to $\backslash$x0B
-\item $\backslash$x $HEX\_DIGIT_1$ $HEX\_DIGIT_2$, equivalent to 
+\item $\backslash$x $HEX\_DIGIT_1$ $HEX\_DIGIT_2$, equivalent to
 
 $\backslash$u\{$HEX\_DIGIT_1$ $HEX\_DIGIT_2$\}.
 \item $\backslash$u $HEX\_DIGIT_1$ $HEX\_DIGIT_2$ $HEX\_DIGIT_3$ $HEX\_DIGIT_4$, equivalent to $\backslash$u\{$HEX\_DIGIT_1$ $HEX\_DIGIT_2$ $HEX\_DIGIT_3$ $HEX\_DIGIT_4$\}.
@@ -2793,21 +2801,21 @@ It is a compile-time error if a non-raw string literal contains a character sequ
      stringInterpolation
     .
 
-    
+
  {\bf stringContentTDQ:}\~{}( `$\backslash$' $|$  `{\escapegrammar \texttt{"""}}' $|$ `\$');
      stringInterpolation
-    .    
+    .
 
  {\bf stringContentTSQ:}\~{}( `$\backslash$' $|$ `{\escapegrammar \code{'}\code{'}\code{'}}' $|$ `\$');
      stringInterpolation
     .
-    
+
 {\bf NEWLINE:}$\backslash$ n;
       $\backslash$ r
     .
 
  \end{grammar}
- 
+
 \LMHash{}
 All string literals implement the built-in class \code{String}. It is a compile-time error for a class to attempt to extend, mix in or implement \code{String}. Invoking the getter \code{runtimeType} on a string literal returns the \code{Type} object that is the value of the expression \code{String}. The static type of a string literal is \code{String}.
 
@@ -2822,14 +2830,14 @@ It is possible to embed expressions within non-raw string literals, such that th
       `\$' `\{' expression `\}' % could be top level expression, no?
     .
  \end{grammar}
- 
-\commentary{The reader will note that the expression inside the interpolation could itself include strings, which could again be interpolated recursively. 
+
+\commentary{The reader will note that the expression inside the interpolation could itself include strings, which could again be interpolated recursively.
 }
 
 \LMHash{}
 An unescaped \$ character in a string signifies the beginning of an interpolated expression.  The \$ sign may be followed by either:
 \begin{itemize}
-\item A single identifier $id$ that must not contain the \$ character. 
+\item A single identifier $id$ that must not contain the \$ character.
 \item An expression $e$ delimited by curly braces.
 \end{itemize}
 
@@ -2840,7 +2848,7 @@ The form \code{\$id} is equivalent to the form \code{\$\{id\}}.  An interpolated
 \LMLabel{symbols}
 
 \LMHash{}
-A {\em symbol literal} denotes the name of a declaration in a Dart program. 
+A {\em symbol literal} denotes the name of a declaration in a Dart program.
 
 \begin{grammar}
 {\bf symbolLiteral:}
@@ -2848,13 +2856,13 @@ A {\em symbol literal} denotes the name of a declaration in a Dart program.
 \end{grammar}
 
 \LMHash{}
-A symbol literal \code{\#id} where \code{id} does not begin with an underscore ('\code{\_}')  is equivalent to the expression \code{\CONST{} Symbol('id')}.  
+A symbol literal \code{\#id} where \code{id} does not begin with an underscore ('\code{\_}')  is equivalent to the expression \code{\CONST{} Symbol('id')}.
 
 \LMHash{}
 A symbol literal \code{\#\_id} evaluates to the object that would be returned by the call \code{mirror.getPrivateSymbol('id')} where mirror is an instance of the class \code{LibraryMirror} defined in the library \code{dart:mirrors}, reflecting the current library.
 
 \rationale{
-One may well ask what is the motivation for introducing literal symbols? In some languages, symbols are canonicalized whereas strings are not. However literal strings are already canonicalized in Dart.  Symbols are slightly easier to type compared to strings and their use can become strangely addictive, but this is not nearly sufficient justification for adding a literal form to the language. The primary motivation is related to the use of reflection and a web specific practice known as minification. 
+One may well ask what is the motivation for introducing literal symbols? In some languages, symbols are canonicalized whereas strings are not. However literal strings are already canonicalized in Dart.  Symbols are slightly easier to type compared to strings and their use can become strangely addictive, but this is not nearly sufficient justification for adding a literal form to the language. The primary motivation is related to the use of reflection and a web specific practice known as minification.
 
 Minification compresses identifiers consistently throughout a program in order to reduce download size.  This practice poses difficulties for reflective programs that refer to program declarations via strings. A string will refer to an identifier in the source, but the identifier will no longer be used in the minified code, and reflective code using these would fail.  Therefore, Dart reflection uses  objects of type \code{Symbol} rather than strings. Instances of \code{Symbol} are guaranteed to be stable with repeat to minification. Providing a literal form for symbols makes reflective code easier to read and write. The fact that symbols are easy to type and can often act as convenient substitutes for enums are secondary benefits.
 }
@@ -2866,7 +2874,7 @@ The static type of a symbol literal is \code{Symbol}.
 \LMLabel{lists}
 
 \LMHash{}
-A {\em list literal} denotes a list, which is an integer indexed collection of objects. 
+A {\em list literal} denotes a list, which is an integer indexed collection of objects.
 
 \begin{grammar}
 {\bf listLiteral:}
@@ -2890,7 +2898,7 @@ It is a compile-time error if an element of a constant list literal is not a com
 The value of a constant list literal  \CONST{} $<E>[e_1\ldots e_n]$ is an object $a$ whose class implements the built-in class $List<E>$. The $i$th element of $a$ is $v_{i+1}$, where $v_i$ is the value of the compile-time expression $e_i$.  The value of a constant list literal  \CONST{} $[e_1 \ldots e_n]$ is defined as the value of the constant list literal \CONST{}$ < \DYNAMIC{}>[e_1\ldots e_n]$.
 
 \LMHash{}
-Let $list_1 =$ \CONST{} $<V>[e_{11} \ldots e_{1n}]$ and $list_2 =$  \CONST{} $<U>[e_{21} \ldots e_{2n}]$ be two constant list literals and let the  elements of $list_1$ and $list_2$  evaluate to  $o_{11} \ldots o_{1n}$ and $o_{21} \ldots o_{2n}$ respectively. Iff \code{identical($o_{1i}$, $o_{2i}$)} for $i \in 1.. n$ and $V = U$ then \code{identical($list_1$, $list_2$)}. 
+Let $list_1 =$ \CONST{} $<V>[e_{11} \ldots e_{1n}]$ and $list_2 =$  \CONST{} $<U>[e_{21} \ldots e_{2n}]$ be two constant list literals and let the  elements of $list_1$ and $list_2$  evaluate to  $o_{11} \ldots o_{1n}$ and $o_{21} \ldots o_{2n}$ respectively. Iff \code{identical($o_{1i}$, $o_{2i}$)} for $i \in 1.. n$ and $V = U$ then \code{identical($list_1$, $list_2$)}.
 
 \commentary{In other words, constant list literals are canonicalized.}
 
@@ -2899,10 +2907,10 @@ A run-time list literal $<E>[e_1 \ldots e_n]$  is evaluated as follows:
 \begin{itemize}
 \item
 First, the expressions $e_1 \ldots e_n$ are evaluated in order they appear in the program, yielding objects $o_1 \ldots o_n$.
-\item A fresh instance  (\ref{generativeConstructors}) $a$, of size $n$,  whose class implements the built-in class $List<E>$ is allocated. 
+\item A fresh instance  (\ref{generativeConstructors}) $a$, of size $n$,  whose class implements the built-in class $List<E>$ is allocated.
 \item
 The operator \code{[]=} is invoked on $a$ with  first  argument $i$ and second argument
-%The $i$th element of $a$ is set to 
+%The $i$th element of $a$ is set to
 $o_{i+1}, 0 \le i < n$.
 \item
 The result of the evaluation is $a$.
@@ -2910,7 +2918,7 @@ The result of the evaluation is $a$.
 
 
 \commentary{
-Note that this document does not specify an order in which the elements are set. This allows for parallel assignments into the list if an implementation so desires.  The order can only be observed in checked mode (and may not be relied upon): if element $i$ is not a subtype of the element type of the list, a dynamic type error will occur when $a[i]$ is assigned $o_{i-1}$. 
+Note that this document does not specify an order in which the elements are set. This allows for parallel assignments into the list if an implementation so desires.  The order can only be observed in checked mode (and may not be relied upon): if element $i$ is not a subtype of the element type of the list, a dynamic type error will occur when $a[i]$ is assigned $o_{i-1}$.
 }
 
 \LMHash{}
@@ -2919,7 +2927,7 @@ A runtime list literal  $[e_1 \ldots e_n]$ is evaluated as  $< \DYNAMIC{}>[e_1\l
 
 \commentary{
 There is no restriction precluding nesting of list literals. It follows from the rules above that
-$<List<int>>[[1, 2, 3], [4, 5, 6]]$ is a list with type parameter $List<int>$, containing two lists with type parameter  \DYNAMIC{}. 
+$<List<int>>[[1, 2, 3], [4, 5, 6]]$ is a list with type parameter $List<int>$, containing two lists with type parameter  \DYNAMIC{}.
 }
 
 \LMHash{}
@@ -2931,12 +2939,12 @@ It is tempting to assume that the type of the list literal would be computed bas
 
 %Invoking the getter \code{runtimeType} on a list literal returns the \code{Type} object that is the value of the expression \code{List}. The static type of a list literal is \code{List}.
 % what about generics?
-    
+
 \subsection{Maps}
 \LMLabel{maps}
 
 \LMHash{}
-A {\em map literal} denotes a map object. 
+A {\em map literal} denotes a map object.
 
 \begin{grammar}
 {\bf mapLiteral:}
@@ -2945,28 +2953,28 @@ A {\em map literal} denotes a map object.
 
 {\bf mapLiteralEntry:}
         % identifier `{\escapegrammar :}' expression;
-	expression `{\escapegrammar :}' expression 
+	expression `{\escapegrammar :}' expression
     .
 \end{grammar}
 
 \LMHash{}
-A {\em map literal} consists of zero or more entries. Each entry has a {\em key} and a {\em value}.  Each key and each value is denoted by an expression. 
- 
+A {\em map literal} consists of zero or more entries. Each entry has a {\em key} and a {\em value}.  Each key and each value is denoted by an expression.
+
 \LMHash{}
 If a map literal begins with the reserved word \CONST{}, it is a {\em constant map literal} which is a compile-time constant (\ref{constants}) and therefore evaluated at compile-time. Otherwise, it is a {\em run-time map literal} and it is evaluated at run-time. Only run-time map literals can be mutated
 after they are created. Attempting to mutate a constant map literal will result in a dynamic error.
 
 \LMHash{}
-It is a compile-time error if either a key or a value of an entry in a constant map literal is not a compile-time constant. It is a compile-time error if the key of an entry in a constant map literal is an instance of a class that implements the operator $==$ unless the key is a 
-%symbol, 
-string, an integer, a literal symbol or the result of invoking a constant constructor of class \cd{Symbol}. 
-It is a compile-time error if the type arguments of a constant map literal include a type parameter. 
+It is a compile-time error if either a key or a value of an entry in a constant map literal is not a compile-time constant. It is a compile-time error if the key of an entry in a constant map literal is an instance of a class that implements the operator $==$ unless the key is a
+%symbol,
+string, an integer, a literal symbol or the result of invoking a constant constructor of class \cd{Symbol}.
+It is a compile-time error if the type arguments of a constant map literal include a type parameter.
 
 \LMHash{}
 The value of a constant map literal  \CONST{}$ <K, V>\{k_1:e_1\ldots k_n :e_n\}$ is an object $m$ whose class implements the built-in class $Map<K, V>$. The entries of $m$ are $u_i:v_i, i \in 1 .. n$, where $u_i$ is the value of the compile-time expression $k_i$ and $v_i$ is the value of the compile-time expression $e_i$.  The value of a constant map literal  \CONST{} $\{k_1:e_1\ldots k_n :e_n\}$ is defined as the value of a constant map literal \CONST{} $<\DYNAMIC{}, \DYNAMIC{}>\{k_1:e_1\ldots k_n :e_n\}$.
 
 \LMHash{}
-Let $map_1 =$ \CONST{}$ <K, V>\{k_{11}:e_{11} \ldots k_{1n} :e_{1n}\}$ and  $map_2 =$  \CONST{}$ <J, U>\{k_{21}:e_{21} \ldots k_{2n} :e_{2n}\}$ be two constant map literals. Let the keys of $map_1$ and $map_2$ evaluate to  $s_{11} \ldots  s_{1n}$  and   $s_{21} \ldots  s_{2n}$ respectively, and let the elements of $map_1$ and $map_2$ evaluate to $o_{11} \ldots  o_{1n}$ and $o_{21} \ldots  o_{2n}$ respectively. Iff \code{identical($o_{1i}$, $o_{2i}$)}  and \code{identical($s_{1i}$, $s_{2i}$)} for $i \in 1.. n$, and $K = J, V = U$ then \code{identical($map_1$, $map_2$)}. 
+Let $map_1 =$ \CONST{}$ <K, V>\{k_{11}:e_{11} \ldots k_{1n} :e_{1n}\}$ and  $map_2 =$  \CONST{}$ <J, U>\{k_{21}:e_{21} \ldots k_{2n} :e_{2n}\}$ be two constant map literals. Let the keys of $map_1$ and $map_2$ evaluate to  $s_{11} \ldots  s_{1n}$  and   $s_{21} \ldots  s_{2n}$ respectively, and let the elements of $map_1$ and $map_2$ evaluate to $o_{11} \ldots  o_{1n}$ and $o_{21} \ldots  o_{2n}$ respectively. Iff \code{identical($o_{1i}$, $o_{2i}$)}  and \code{identical($s_{1i}$, $s_{2i}$)} for $i \in 1.. n$, and $K = J, V = U$ then \code{identical($map_1$, $map_2$)}.
 
 \commentary{In other words, constant map literals are canonicalized.}
 
@@ -2976,8 +2984,8 @@ A runtime map literal $<K, V>\{k_1:e_1\ldots k_n :e_n\}$  is evaluated as follow
 \item
 First, the expression $k_i$ is evaluated yielding object $u_i$, the $e_i$ is vaulted yielding object $o_i$, for $i \in 1..n$ in left to right order, yielding objects $u_1, o_1\ldots u_n, o_n$.
 \item  A fresh instance (\ref{generativeConstructors}) $m$ whose class implements the built-in class
- 
- $Map<K, V>$ is allocated. 
+
+ $Map<K, V>$ is allocated.
 \item
 The operator \code{[]=} is invoked on $m$ with  first  argument $u_i$ and second argument $o_i,  i \in 1.. n$.
 \item
@@ -2986,7 +2994,7 @@ The result of the evaluation is $m$.
 
 
 \LMHash{}
-A runtime map literal  $\{k_1:e_1\ldots k_n :e_n\}$ is evaluated as  
+A runtime map literal  $\{k_1:e_1\ldots k_n :e_n\}$ is evaluated as
 
 $<\DYNAMIC{},  \DYNAMIC{}>\{k_1:e_1\ldots k_n :e_n\}$.
 
@@ -2994,15 +3002,15 @@ $<\DYNAMIC{},  \DYNAMIC{}>\{k_1:e_1\ldots k_n :e_n\}$.
 Iff all the keys in a map literal are compile-time constants, it is a static warning if the values of any two keys in a map literal are equal.
 
 \LMHash{}
-A map literal is ordered: iterating over the keys and/or values of the maps always happens in the 
+A map literal is ordered: iterating over the keys and/or values of the maps always happens in the
  order the keys appeared in the source code.
 
 \commentary{
 Of course, if a key repeats, the order is defined by first occurrence, but the value is defined by the last.
-} 
+}
 
 \LMHash{}
-The static type of a map literal of the form  \CONST{}$ <K, V>\{k_1:e_1\ldots k_n :e_n\}$ or the form $<K, V>\{k_1:e_1\ldots k_n :e_n\}$ is $Map<K, V>$. The static type a map literal of the form  \CONST{}$\{k_1:e_1\ldots k_n :e_n\}$ or the form $\{k_1:e_1\ldots k_n :e_n\}$ is $Map<\DYNAMIC{},  \DYNAMIC{}>$. 
+The static type of a map literal of the form  \CONST{}$ <K, V>\{k_1:e_1\ldots k_n :e_n\}$ or the form $<K, V>\{k_1:e_1\ldots k_n :e_n\}$ is $Map<K, V>$. The static type a map literal of the form  \CONST{}$\{k_1:e_1\ldots k_n :e_n\}$ or the form $\{k_1:e_1\ldots k_n :e_n\}$ is $Map<\DYNAMIC{},  \DYNAMIC{}>$.
 
 
 \subsection{Throw}
@@ -3013,23 +3021,23 @@ The {\em throw expression}  is used to raise an exception.
 
  \begin{grammar}
 {\bf throwExpression:}
-     \THROW{} expression 
+     \THROW{} expression
     .
-    
+
    {\bf throwExpressionWithoutCascade:}
-     \THROW{} expressionWithoutCascade 
+     \THROW{} expressionWithoutCascade
     .
- 
+
  \end{grammar}
- 
+
 \LMHash{}
- The {\em current exception} is the last exception raised and not subsequently caught at a given moment during runtime. 
+ The {\em current exception} is the last exception raised and not subsequently caught at a given moment during runtime.
 
 \LMHash{}
  Evaluation of a throw expression of the form  \code{\THROW{} $e$;} proceeds as follows:
- 
+
 \LMHash{}
-The expression $e$ is evaluated yielding a value $v$. 
+The expression $e$ is evaluated yielding a value $v$.
 
 \commentary{
 There is no requirement that the expression $e$ evaluate to a special kind of exception or error object.
@@ -3038,11 +3046,11 @@ There is no requirement that the expression $e$ evaluate to a special kind of ex
 \LMHash{}
 If $e$ evaluates to \NULL{} (\ref{null}), then a \code{NullThrownError} is thrown. Otherwise the current exception is set to $v$ and the current return value (\ref{return}) becomes undefined.
 
-\rationale{The current exception and the current return value must never be simultaneously defined, as they represent mutually exclusive options for exiting the current function. 
+\rationale{The current exception and the current return value must never be simultaneously defined, as they represent mutually exclusive options for exiting the current function.
 }
 
 \LMHash{}
-Let $f$ be the immediately enclosing function. 
+Let $f$ be the immediately enclosing function.
 
 \LMHash{}
 If $f$ is synchronous (\ref{functions}), control is transferred to the nearest dynamically enclosing exception handler.
@@ -3069,16 +3077,16 @@ The static type of a throw expression is $\bot$.
 \LMLabel{functionExpressions}
 
 \LMHash{}
-A {\em function literal} is an object that encapsulates an executable unit of code. 
+A {\em function literal} is an object that encapsulates an executable unit of code.
 
 \begin{grammar}
 {\bf functionExpression:}
     formalParameterList functionBody
     .
- \end{grammar}   
- 
+ \end{grammar}
+
 \LMHash{}
-The class of a function literal implements the built-in class \code{Function}.   
+The class of a function literal implements the built-in class \code{Function}.
 %Invoking the getter \code{runtimeType} on a function literal returns the \code{Type} object that is the value of the expression \code{Function}.
 % not necessarily
 
@@ -3086,35 +3094,35 @@ The class of a function literal implements the built-in class \code{Function}.
 %Q{Can anyone implement it? Then we should define things via call}
 
 \LMHash{}
-The static type of a function literal of the form 
+The static type of a function literal of the form
 
-$(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k} = d_k]) => e$ 
-is 
+$(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k} = d_k]) => e$
+is
 
-$(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow T_0$, where $T_0$ is the static type of $e$. 
+$(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow T_0$, where $T_0$ is the static type of $e$.
 
 \LMHash{}
-The static type of a function literal of the form 
+The static type of a function literal of the form
 
 $(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k} = d_k])$ \ASYNC{} $=> e$
 is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow Future<flatten(T_0)>$, where $T_0$ is the static type of $e$ and  $flatten(T)$ is defined as follows:
 
- If $T = Future<S>$ then $flatten(T) = flatten(S)$. 
- 
- Otherwise if $T <: Future$ then let $S$ be a type such that $T << Future<S>$ and for all $R$, if $T << Future<R>$ then $S << R$.  
+ If $T = Future<S>$ then $flatten(T) = flatten(S)$.
+
+ Otherwise if $T <: Future$ then let $S$ be a type such that $T << Future<S>$ and for all $R$, if $T << Future<R>$ then $S << R$.
 
 \rationale{
 This ensures that $Future<S>$ is the most specific instantiation of \cd{Future} that is a super type of $T$.
 }
 
-Then $flatten(T) =  S$.  
+Then $flatten(T) =  S$.
 
 In any other circumstance, $flatten(T) = T$.
 
 
 
 \rationale{
-We collapse multiple layers of futures into one. If $e$ evaluates to a future $f$, the future will not invoke its \code{then()} callback until f completes to a non-future value, and so the result of an await is never a future, and the result of an async function will never have type \code{Future$<X>$} where $X$ itself is an invocation of \code{Future}. 
+We collapse multiple layers of futures into one. If $e$ evaluates to a future $f$, the future will not invoke its \code{then()} callback until f completes to a non-future value, and so the result of an await is never a future, and the result of an async function will never have type \code{Future$<X>$} where $X$ itself is an invocation of \code{Future}.
 
 The  exception to that would be a type $X$ that extended or implemented \code{Future}. In that case, only one unwrapping takes place. As an example of why this is done, consider
 
@@ -3126,73 +3134,73 @@ Here, a naive definition of $flatten$ diverges; there is not even a fixed point.
 
 
 \LMHash{}
-The static type of a function literal of the form 
+The static type of a function literal of the form
 
-$(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots,  T_{n+k}$ $x_{n+k} : d_k\}) => e$ 
-is 
+$(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots,  T_{n+k}$ $x_{n+k} : d_k\}) => e$
+is
 
-$(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightarrow T_0$, where $T_0$ is the static type of $e$. 
+$(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightarrow T_0$, where $T_0$ is the static type of $e$.
 
 \LMHash{}
-The static type of a function literal of the form 
+The static type of a function literal of the form
 
 $(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots,  T_{n+k}$ $x_{n+k} : d_k\})$ \ASYNC{}  $=> e$
 
-is $(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightarrow Future<flatten(T_0)>$, where $T_0$ is the static type of $e$. 
+is $(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightarrow Future<flatten(T_0)>$, where $T_0$ is the static type of $e$.
 
 \LMHash{}
-The static type of a function literal of the form  
+The static type of a function literal of the form
 
-$(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k}= d_k])\{s\}$ 
+$(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k}= d_k])\{s\}$
 
 is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow  \DYNAMIC{}$.
 
 \LMHash{}
-The static type of a function literal of the form  
+The static type of a function literal of the form
 
-$(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k}= d_k])$ $ \ASYNC{}$ $\{s\}$ 
-is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow Future$. 
+$(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k}= d_k])$ $ \ASYNC{}$ $\{s\}$
+is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow Future$.
 
 \LMHash{}
-The static type of a function literal of the form  
+The static type of a function literal of the form
 
-$(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k}= d_k])$ $ \ASYNC*{}$ $\{s\}$ 
-is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow Stream$. 
+$(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k}= d_k])$ $ \ASYNC*{}$ $\{s\}$
+is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow Stream$.
 
 \LMHash{}
-The static type of a function literal of the form  
+The static type of a function literal of the form
 
-$(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k}= d_k])$ $ \SYNC*{}$ $\{s\}$ 
-is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow Iterable$. 
+$(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k}= d_k])$ $ \SYNC*{}$ $\{s\}$
+is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow Iterable$.
 
 
 \LMHash{}
-The static type of a function literal of the form  
+The static type of a function literal of the form
 
-$(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k}= d_k])\{s\}$ 
+$(T_1$ $a_1, \ldots, T_n$ $a_n, [T_{n+1}$ $x_{n+1} = d_1, \ldots,  T_{n+k}$ $x_{n+k}= d_k])\{s\}$
 
-is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow  \DYNAMIC{}$. 
+is $(T_1 \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \rightarrow  \DYNAMIC{}$.
 
 
 \LMHash{}
-The static type of a function literal of the form  
+The static type of a function literal of the form
 
 $(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots,  T_{n+k}$ $x_{n+k} : d_k\})$ $\ASYNC{}$ $\{s\}$
- 
+
 is $(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightarrow  Future{}$.
 
 \LMHash{}
-The static type of a function literal of the form  
+The static type of a function literal of the form
 
 $(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots,  T_{n+k}$ $x_{n+k} : d_k\})$ $\ASYNC*{}$ $\{s\}$
- 
+
 is $(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightarrow  Stream{}$.
 
 \LMHash{}
-The static type of a function literal of the form  
+The static type of a function literal of the form
 
 $(T_1$ $a_1, \ldots, T_n$ $a_n, \{T_{n+1}$ $x_{n+1} : d_1, \ldots,  T_{n+k}$ $x_{n+k} : d_k\})$ $\SYNC*{}$ $\{s\}$
- 
+
 is $(T_1 \ldots, T_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \rightarrow  Iterable{}$.
 
 \LMHash{}
@@ -3215,44 +3223,44 @@ The reserved word \THIS{} denotes the target of the current instance member invo
 The static type of \THIS{} is the interface of the immediately enclosing class.
 
 \commentary{
-We do not support self-types at this point. 
+We do not support self-types at this point.
 }
 
 \LMHash{}
-It is a compile-time error if \THIS{} appears, implicitly or explicitly,  in a top-level function or variable initializer,  in a factory constructor, or in a static method or variable initializer, or in the initializer of an instance variable. 
+It is a compile-time error if \THIS{} appears, implicitly or explicitly,  in a top-level function or variable initializer,  in a factory constructor, or in a static method or variable initializer, or in the initializer of an instance variable.
 
 \subsection{ Instance Creation}
 \LMLabel{instanceCreation}
 
 \LMHash{}
-Instance creation expressions invoke constructors to produce instances. 
+Instance creation expressions invoke constructors to produce instances.
 
-%It is a compile-time error if any of the type arguments to a constructor of a generic type invoked by a new expression or a constant object expression do not denote types in the enclosing lexical scope. 
+%It is a compile-time error if any of the type arguments to a constructor of a generic type invoked by a new expression or a constant object expression do not denote types in the enclosing lexical scope.
 
 %It is a compile-time error if a constructor of a non-generic type invoked by a new expression or a constant object expression is passed any type arguments. It is a compile-time error if a constructor of a generic type with $n$ type parameters invoked by a new expression or a constant object expression is passed $m$ type arguments where $m \ne n$, or if any of its type arguments is  misconstructed (\ref{parameterizedTypes}).
 
 \LMHash{}
 It is a static type warning if
-the type $T$ in an instance creation expression of one of  the forms 
+the type $T$ in an instance creation expression of one of  the forms
 
-\NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$,  
+\NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$,
 
 \NEW{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$,
 
-\CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$,  
+\CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$,
 
 \CONST{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ is malformed (\ref{dynamicTypeSystem}) or malbounded (\ref{parameterizedTypes}).
 
 \LMHash{}
-It is a compile-time error if the type $T$ in an instance creation expression of one of the forms 
+It is a compile-time error if the type $T$ in an instance creation expression of one of the forms
 
-\NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$,  
+\NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$,
 
 \NEW{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$,
 
-\CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$,  
+\CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$,
 
-\CONST{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ 
+\CONST{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$
 
 is an enumerated type (\ref{enums}).
 %any of the type arguments to a constructor of a generic type $G$ invoked by a new expression or a constant object expression are not subtypes of the bounds of the corresponding formal type parameters of $G$.
@@ -3271,49 +3279,49 @@ The {\em new expression} invokes a constructor (\ref{constructors}).
 \end{grammar}
 
 \LMHash{}
-Let $e$ be a new expression of the form  
+Let $e$ be a new expression of the form
 
-\NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ or the form  
+\NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ or the form
 
-\NEW{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$. 
+\NEW{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 
 %It is a runtime type error if
 %the type $T$  is malformed.
 %It is a static warning if $T$ is a malformed type.
 
-%not a class accessible in the current scope,  optionally followed by type arguments. 
+%not a class accessible in the current scope,  optionally followed by type arguments.
 
 \LMHash{}
 If $T$ is  a class or parameterized type accessible in the current scope then:
 \begin{itemize}
 \item
-If $e$ is of the form \NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ it is a static warning if $T.id$ is not the name of a constructor declared by the type $T$. If $e$ is of the form  \NEW{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ it is a static warning if the type $T$ does not declare a constructor with the same name as the declaration of $T$. 
+If $e$ is of the form \NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ it is a static warning if $T.id$ is not the name of a constructor declared by the type $T$. If $e$ is of the form  \NEW{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ it is a static warning if the type $T$ does not declare a constructor with the same name as the declaration of $T$.
 \end{itemize}
 
 \LMHash{}
-If $T$ is a parameterized type (\ref{parameterizedTypes}) $S<U_1,  \ldots, U_m>$, let $R = S$.  
-%It is a 
+If $T$ is a parameterized type (\ref{parameterizedTypes}) $S<U_1,  \ldots, U_m>$, let $R = S$.
+%It is a
 %compile-time CHANGED
 %runtime type
-%error if $S$ is not a generic (\ref{generics}) type with $m$ type parameters. 
+%error if $S$ is not a generic (\ref{generics}) type with $m$ type parameters.
 If $T$ is not a parameterized type, let $R = T$.
-Furthermore, if $e$ is of the form \NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ then let  $q$ be the constructor  $T.id$, otherwise let $q$ be the constructor $T$. 
+Furthermore, if $e$ is of the form \NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ then let  $q$ be the constructor  $T.id$, otherwise let $q$ be the constructor $T$.
 
 \LMHash{}
 If $R$ is a generic with $l = m$ type parameters then
 \begin{itemize}
 \item  If $T$ is not a parameterized type, then for $ i \in 1 .. l$, let $V_i =  \DYNAMIC{}$.
-\item  If $T$ is  a parameterized type then let $V_i = U_i$ for $ i \in 1 .. m$.  
+\item  If $T$ is  a parameterized type then let $V_i = U_i$ for $ i \in 1 .. m$.
 \end{itemize}
 
 \LMHash{}
-If $R$ is a generic with $l \ne m$ type parameters then for $ i \in 1 .. l$, let $V_i =  \DYNAMIC{}$. In any other case, let $V_i = U_i$ for $ i \in 1 .. m$.  
+If $R$ is a generic with $l \ne m$ type parameters then for $ i \in 1 .. l$, let $V_i =  \DYNAMIC{}$. In any other case, let $V_i = U_i$ for $ i \in 1 .. m$.
 
 \LMHash{}
 Evaluation of $e$ proceeds as follows:
 
 \LMHash{}
-First, the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ is evaluated. 
+First, the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ is evaluated.
 
 \LMHash{}
 If $T$ is a deferred type with prefix $p$, then if $p$ has not been successfully loaded, a dynamic error occurs.
@@ -3344,7 +3352,7 @@ Next,  $q$ is executed  with \THIS{} bound to $i$,  the type parameters (if any)
 Otherwise, $q$ is a factory constructor (\ref{factories}). Then:
 
 \LMHash{}
-If $q$ is a redirecting factory constructor of the form $T(p_1, \ldots, p_{n+k}) = c;$ or of the form  $T.id(p_1, \ldots, p_{n+k}) = c;$ then the result of the evaluation of $e$ is equivalent to evaluating the expression 
+If $q$ is a redirecting factory constructor of the form $T(p_1, \ldots, p_{n+k}) = c;$ or of the form  $T.id(p_1, \ldots, p_{n+k}) = c;$ then the result of the evaluation of $e$ is equivalent to evaluating the expression
 
 $[V_1,  \ldots, V_m/T_1,  \ldots, T_m]($\code{\NEW{} $c(a_1, \ldots, a_n, x_{n+1}: a_{n+1}, \ldots, x_{n+k}: a_{n+k}))$}.  If evaluation of $q$ causes $q$ to be re-evaluated cyclically, a runtime error occurs.
 
@@ -3355,23 +3363,23 @@ Otherwise, the body of $q$ is executed with respect to the bindings that resulte
 \LMHash{}
 It is a static warning if $q$ is a constructor of an abstract class and $q$ is not a factory constructor.
 
-\commentary{The above gives precise meaning to the idea that instantiating an abstract class leads to a warning. 
+\commentary{The above gives precise meaning to the idea that instantiating an abstract class leads to a warning.
 A similar clause applies to constant object creation in the next section.
-} 
+}
 
 \rationale{In particular, a factory constructor can be declared in an abstract class and used safely, as it will either produce a valid instance or lead to a warning inside its own declaration.
 }
 
 \LMHash{}
-The static type of an instance creation expression of either the form 
+The static type of an instance creation expression of either the form
 
-\NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ 
+\NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$
 
-or the form 
+or the form
 
-\NEW{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ 
+\NEW{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$
 
-is $T$.  
+is $T$.
 It is a static warning if the static type of $a_i, 1 \le i \le n+ k$ may not be assigned to the type of the corresponding formal parameter of the constructor $T.id$ (respectively $T$).
 
 
@@ -3380,7 +3388,7 @@ It is a static warning if the static type of $a_i, 1 \le i \le n+ k$ may not be
 \LMLabel{const}
 
 \LMHash{}
-A {\em constant object expression} invokes a constant constructor (\ref{constantConstructors}). 
+A {\em constant object expression} invokes a constant constructor (\ref{constantConstructors}).
 
 \begin{grammar}
 {\bf constObjectExpression:}
@@ -3389,9 +3397,9 @@ A {\em constant object expression} invokes a constant constructor (\ref{constant
 \end{grammar}
 
 \LMHash{}
-Let $e$ be a constant object expression of the form  
+Let $e$ be a constant object expression of the form
 
-\CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ 
+\CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$
 
 or the form  \CONST{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$. It is a compile-time error if $T$ does not denote a class accessible in the current scope.  It is a compile-time error if $T$ is a deferred type (\ref{staticTypes}).
 
@@ -3401,40 +3409,40 @@ or the form  \CONST{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}:
 If $T$ is a parameterized type, it is a compile-time error if $T$ includes a type variable among its type arguments.
 
 \LMHash{}
-If $e$ is of the form \CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ it is a compile-time error if $T.id$ is not the name of a constant constructor declared by the type $T$. If $e$ is of the form  \CONST{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ it is a compile-time error if the type $T$ does not declare a constant constructor with the same name as the declaration of $T$. 
+If $e$ is of the form \CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ it is a compile-time error if $T.id$ is not the name of a constant constructor declared by the type $T$. If $e$ is of the form  \CONST{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ it is a compile-time error if the type $T$ does not declare a constant constructor with the same name as the declaration of $T$.
 
 \LMHash{}
 In all of the above cases, it is a compile-time error if $a_i,  i\in 1 .. n + k$, is not a compile-time constant expression.
 
 %If $T$ is a parameterized type (\ref{parameterizedTypes}) $S<U_1,  \ldots, U_m>$, let $R = S$.  It is a compile-time error if $T$ is is malformed. If $T$ is not a parameterized type, let $R = T$.
- %Finally, 
-% If $T$ is a generic with $l$ retype parameters, then for all $ i \in 1 .. l$, let $V_i =  \DYNAMIC{}$.  
+ %Finally,
+% If $T$ is a generic with $l$ retype parameters, then for all $ i \in 1 .. l$, let $V_i =  \DYNAMIC{}$.
 
 \LMHash{}
 Evaluation of $e$ proceeds as follows:
 
 \LMHash{}
-First, if $e$ is of the form 
+First, if $e$ is of the form
 
-\CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ 
+\CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$
 
-then let $i$ be the value of the expression 
+then let $i$ be the value of the expression
 
-\NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$. 
+\NEW{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 
 \LMHash{}
-Otherwise, $e$ must be of the form  
+Otherwise, $e$ must be of the form
 
-\CONST{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$, 
+\CONST{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$,
 
-in which case let $i$ be the result of evaluating 
+in which case let $i$ be the result of evaluating
 
-\NEW{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$. 
+\NEW{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 
 \LMHash{}
 Then:
 \begin{itemize}
-\item If during execution of the program, a constant object expression has already evaluated to an instance $j$ of class $R$ with type arguments $V_i, 1 \le i \le m$, then: 
+\item If during execution of the program, a constant object expression has already evaluated to an instance $j$ of class $R$ with type arguments $V_i, 1 \le i \le m$, then:
 \begin{itemize}
 \item For each instance variable $f$ of $i$, let $v_{if}$ be the value of the field $f$ in $i$, and let $v_{jf}$ be the value of the field $f$ in $j$. If  \code{identical($v_{if}$, $v_{jf}$)} for all fields $f$ in $i$, then the value of $e$ is $j$, otherwise the value of $e$ is $i$.
 \end{itemize}
@@ -3446,13 +3454,13 @@ In other words, constant objects are canonicalized.  In order to determine if an
 }
 
 \LMHash{}
-The static type of a constant object expression of either the form 
+The static type of a constant object expression of either the form
 
-\CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ 
+\CONST{} $T.id(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$
 
-or the form  
+or the form
 
-\CONST{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ 
+\CONST{} $T(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$
 
 is $T$. It is a static warning if the static type of $a_i, 1 \le i \le n+ k$ may not be assigned to the type of the corresponding formal parameter of the constructor $T.id$ (respectively $T$).
 
@@ -3484,12 +3492,12 @@ To see how such situations might arise, consider the following examples:
 \end{dartCode}
 
 \commentary{
-Due to the rules governing constant constructors, evaluating the constructor \code{A()} with the argument \code{''x''} or the argument \code{\CONST{} IntPair(1, 2)} would cause it to throw an exception, resulting in a compile-time error.
+Due to the rules governing constant constructors, evaluating the constructor \code{A()} with the argument \code{"x"} or the argument \code{\CONST{} IntPair(1, 2)} would cause it to throw an exception, resulting in a compile-time error.
 }
 
 
 \LMHash{}
-Given an instance creation expression of the form \CONST{} $q(a_1, \ldots , a_n)$ it is a static warning if $q$ is a constructor of an abstract class  (\ref{abstractInstanceMembers}) but $q$ is not a factory constructor.  
+Given an instance creation expression of the form \CONST{} $q(a_1, \ldots , a_n)$ it is a static warning if $q$ is a constructor of an abstract class  (\ref{abstractInstanceMembers}) but $q$ is not a factory constructor.
 
 
 \subsection{ Spawning an Isolate}
@@ -3509,27 +3517,27 @@ As discussed in section \ref{errorsAndWarnings}, the handling of a suspended iso
 
 \subsection{ Function Invocation}
 \LMLabel{functionInvocation}
- 
+
 \LMHash{}
-Function invocation occurs in the following cases: when a function expression  (\ref{functionExpressions}) is invoked (\ref{functionExpressionInvocation}), when a method (\ref{methodInvocation}), getter (\ref{topLevelGetterInvocation}, \ref{propertyExtraction}) or setter (\ref{assignment}) is invoked or when a constructor is invoked (either via instance creation (\ref{instanceCreation}), constructor redirection (\ref{redirectingConstructors}) or super initialization). The various kinds of function invocation differ as to how the function to be invoked, $f$,  is determined, as well as whether \THIS{} (\ref{this}) is bound. Once $f$ has been determined, the formal parameters of $f$ are bound to corresponding actual arguments. When the body of $f$ is executed it will be executed with the aforementioned bindings. 
+Function invocation occurs in the following cases: when a function expression  (\ref{functionExpressions}) is invoked (\ref{functionExpressionInvocation}), when a method (\ref{methodInvocation}), getter (\ref{topLevelGetterInvocation}, \ref{propertyExtraction}) or setter (\ref{assignment}) is invoked or when a constructor is invoked (either via instance creation (\ref{instanceCreation}), constructor redirection (\ref{redirectingConstructors}) or super initialization). The various kinds of function invocation differ as to how the function to be invoked, $f$,  is determined, as well as whether \THIS{} (\ref{this}) is bound. Once $f$ has been determined, the formal parameters of $f$ are bound to corresponding actual arguments. When the body of $f$ is executed it will be executed with the aforementioned bindings.
 
 \LMHash{}
-If $f$ is marked \ASYNC{} (\ref{functions}), then a fresh instance (\ref{generativeConstructors}) $o$ implementing the built-in class \code{Future} is associated with the invocation and immediately returned to the caller. The body of $f$ is scheduled for execution at some future time. The future $o$ will complete when $f$ terminates. The value used to complete $o$ is the current return value (\ref{return}), if it is defined, and the current exception (\ref{throw}) otherwise. 
+If $f$ is marked \ASYNC{} (\ref{functions}), then a fresh instance (\ref{generativeConstructors}) $o$ implementing the built-in class \code{Future} is associated with the invocation and immediately returned to the caller. The body of $f$ is scheduled for execution at some future time. The future $o$ will complete when $f$ terminates. The value used to complete $o$ is the current return value (\ref{return}), if it is defined, and the current exception (\ref{throw}) otherwise.
 
 \LMHash{}
 If $f$ is marked \ASYNC* (\ref{functions}), then a fresh instance $s$ implementing the built-in class \code{Stream} is associated with the invocation and immediately returned. When $s$ is listened to, execution of the body of $f$ will begin.  When $f$ terminates:
 \begin{itemize}
-\item If the current return value is defined then, if $s$ has been canceled then its cancellation future is completed with \NULL{} (\ref{null}). 
+\item If the current return value is defined then, if $s$ has been canceled then its cancellation future is completed with \NULL{} (\ref{null}).
 \item If the current exception $x$ is defined:
   \begin{itemize}
-  \item $x$ is added to $s$. 
+  \item $x$ is added to $s$.
   \item If $s$ has been canceled then its cancellation future is completed with $x$ as an error.
   \end{itemize}
 \item $s$ is closed.
 \end{itemize}
 
 \rationale{
-When an asynchronous generator's stream has been canceled, cleanup will occur in the \FINALLY{} clauses (\ref{try}) inside the generator. We choose to direct any exceptions that occur at this time to the cancellation future rather than have them be lost. 
+When an asynchronous generator's stream has been canceled, cleanup will occur in the \FINALLY{} clauses (\ref{try}) inside the generator. We choose to direct any exceptions that occur at this time to the cancellation future rather than have them be lost.
 }
 
 \LMHash{}
@@ -3542,11 +3550,11 @@ If $f$ is asynchronous then, when $f$ terminates, any open stream subscriptions
 %When a stream is canceled, the implementation must wait for the cancelation future returned by \cd{cancell()} to complete before proceeding.
 
 \LMHash{}
-If $f$ is marked \SYNC* (\ref{functions}), then a fresh instance $i$ implementing the built-in class \code{Iterable} is associated with the invocation and immediately returned.  
+If $f$ is marked \SYNC* (\ref{functions}), then a fresh instance $i$ implementing the built-in class \code{Iterable} is associated with the invocation and immediately returned.
 
 
 \commentary{
-A Dart implementation will need to provide a specific implementation of \code{Iterable} that will be returned by \SYNC* methods. A typical strategy would be to produce an instance of a subclass of class \code{IterableBase} defined in \code{dart:core}. The only method that needs to be added by the Dart implementation in that case is \code{iterator}.  
+A Dart implementation will need to provide a specific implementation of \code{Iterable} that will be returned by \SYNC* methods. A typical strategy would be to produce an instance of a subclass of class \code{IterableBase} defined in \code{dart:core}. The only method that needs to be added by the Dart implementation in that case is \code{iterator}.
 }
 
 \LMHash{}
@@ -3559,7 +3567,7 @@ The contract explicitly mentions a number of situations where certain iterables
 \LMHash{}
 When iteration over the iterable is started, by getting an iterator $j$ from the iterable and calling \code{moveNext()}, execution of the body of $f$ will begin. When $f$ terminates, $j$ is positioned after its last element, so that its current value is \NULL{} and the current call to \code{moveNext()} on $j$ returns false, as will all further calls.
 
-Each iterator starts a separate computation. If the \SYNC* function is impure, the sequence of values yielded by each iterator may differ. 
+Each iterator starts a separate computation. If the \SYNC* function is impure, the sequence of values yielded by each iterator may differ.
 
 \commentary{
 One can derive more than one iterator from a given iterable.   Note that operations on the iterable itself can create distinct iterators. An example would be \code{length}.  It is conceivable that different iterators might yield sequences of different length. The same care needs to be taken when writing \SYNC* functions as when
@@ -3570,7 +3578,7 @@ yield (and maybe throw a \code{ConcurrentModificationError} if it isn't).
 }
 
 \LMHash{}
-Each iterator runs with its own shallow copies of all local variables; in particular, each iterator has the same initial arguments, even if their bindings are modified by the function. 
+Each iterator runs with its own shallow copies of all local variables; in particular, each iterator has the same initial arguments, even if their bindings are modified by the function.
 \commentary{
 Two executions of an iterator interact only via state outside the function.
 }
@@ -3584,7 +3592,7 @@ If $f$ is synchronous and is not a generator (\ref{functions}) then execution of
 \LMHash{}
 Execution of $f$ terminates when the first of the following occurs:
 \begin{itemize}
-\item An exception is thrown and not caught within the current function activation. 
+\item An exception is thrown and not caught within the current function activation.
 \item A return statement (\ref{return}) immediately nested in the body of $f$ is executed and not intercepted in a \FINALLY{} (\ref{try}) clause.
 \item The last statement of the body completes execution.
 \end{itemize}
@@ -3615,9 +3623,9 @@ Function invocation involves evaluation of the list of actual arguments to the f
  \end{grammar}
 
 \LMHash{}
-Evaluation of an actual argument list of the form 
+Evaluation of an actual argument list of the form
 
-$(a_1, \ldots, a_m, q_1: a_{m+1}, \ldots, q_l: a_{m+l})$ 
+$(a_1, \ldots, a_m, q_1: a_{m+1}, \ldots, q_l: a_{m+l})$
 
 proceeds as follows:
 
@@ -3647,7 +3655,7 @@ If $l > 0$, then it is necessarily the case that $n = h$, because a method canno
 
 
 \LMHash{}
-If  $m < h$, or $m > n$, a \cd{NoSuchMethodError} is thrown. Furthermore, each $q_i, 1 \le i \le l$,  must have a corresponding named parameter in the set $\{p_{n+1}, \ldots, p_{n +k}\}$ or a \cd{NoSuchMethodError} is thrown. Then $p_i$ is bound to $o_i, i \in 1.. m$, and $q_j$  is bound to $o_{m+j}, j \in 1.. l$.  All remaining formal parameters of $f$  are bound to their default values. 
+If  $m < h$, or $m > n$, a \cd{NoSuchMethodError} is thrown. Furthermore, each $q_i, 1 \le i \le l$,  must have a corresponding named parameter in the set $\{p_{n+1}, \ldots, p_{n +k}\}$ or a \cd{NoSuchMethodError} is thrown. Then $p_i$ is bound to $o_i, i \in 1.. m$, and $q_j$  is bound to $o_{m+j}, j \in 1.. l$.  All remaining formal parameters of $f$  are bound to their default values.
 
 \commentary{All of these remaining parameters are necessarily optional and thus have default values.}
 
@@ -3664,16 +3672,16 @@ Let $T_i$ be the static type of $a_i$, let $S_i$ be the type of $p_i, i \in 1 ..
 \LMLabel{unqualifiedInvocation}
 
 \LMHash{}
-An unqualified function invocation $i$ has the form 
+An unqualified function invocation $i$ has the form
 
-$id(a_1, \ldots, a_n, x_{n+1}: a_{n+1}, \ldots, x_{n+k}: a_{n+k})$, 
+$id(a_1, \ldots, a_n, x_{n+1}: a_{n+1}, \ldots, x_{n+k}: a_{n+k})$,
 
-where $id$ is an identifier. 
+where $id$ is an identifier.
 
 \LMHash{}
 If there exists a lexically visible declaration named $id$, let $f_{id}$ be the innermost such declaration. Then:
 \begin{itemize}
-\item 
+\item
 If $f_{id}$ is a prefix object, a compile-time error occurs.
 \item
  If $f_{id}$ is a local function, a library function, a library or static getter or a variable then $i$ is interpreted as a function expression invocation (\ref{functionExpressionInvocation}).
@@ -3700,11 +3708,11 @@ If $i$ does not occur inside a top level or static function, $i$ is equivalent t
 \LMLabel{functionExpressionInvocation}
 
 \LMHash{}
-A function expression invocation $i$ has the form 
+A function expression invocation $i$ has the form
 
-$e_f(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$, 
+$e_f(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$,
 
-where $e_f$ is an expression. If $e_f$ is an identifier $id$, then $id$ must necessarily denote a local function, a library function, a library or static getter or a variable as described above, or $i$ is not considered a function expression invocation. If $e_f$ is a property extraction expression (\ref{propertyExtraction}), then $i$ is is not a function expression invocation and is instead recognized as an ordinary method invocation (\ref{ordinaryInvocation}). 
+where $e_f$ is an expression. If $e_f$ is an identifier $id$, then $id$ must necessarily denote a local function, a library function, a library or static getter or a variable as described above, or $i$ is not considered a function expression invocation. If $e_f$ is a property extraction expression (\ref{propertyExtraction}), then $i$ is is not a function expression invocation and is instead recognized as an ordinary method invocation (\ref{ordinaryInvocation}).
 
 \commentary{
 \code{$a.b(x)$} is parsed as a method invocation of method \code{$b()$} on object \code{$a$}, not as an invocation of getter \code{$b$} on \code{$a$} followed by a function call \code{$(a.b)(x)$}.  If a method or getter \code{$b$} exists, the two will be equivalent. However, if \code{$b$} is not defined on \code{$a$}, the resulting invocation of \code{noSuchMethod()} would differ.  The \code{Invocation} passed to \code{noSuchMethod()} would describe a call to a method \code{$b$} with argument \code{$x$} in the former case, and a call to a getter \code{$b$} (with no arguments) in the latter.
@@ -3720,8 +3728,8 @@ The implication of this definition, and the other definitions involving the meth
 }
 
 \LMHash{}
-It is a static warning if the static type $F$ of $e_f$ may not be assigned to a function type.  If $F$ is not a function type, the static type of $i$ is \DYNAMIC{}. Otherwise 
-the static type of $i$ is the declared return type of  $F$.  
+It is a static warning if the static type $F$ of $e_f$ may not be assigned to a function type.  If $F$ is not a function type, the static type of $i$ is \DYNAMIC{}. Otherwise
+the static type of $i$ is the declared return type of  $F$.
 %\item Let $T_i$ be the static type of $a_i, i \in 1 .. n+k$. It is a static warning if $F$ is not a supertype of  $(T_1, \ldots, T_n, [T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}]) \to \bot$.
 %\end{itemize}
 
@@ -3739,7 +3747,7 @@ The result of  a lookup of method $m$ in class $C$ with respect to library $L$ i
 If $C$ declares a concrete instance method named $m$ that is accessible to $L$,  then that method is the result of the lookup, and we say that the method was {\em looked up in $C$}. Otherwise, if $C$ has a superclass $S$, then the result of the lookup is the result of looking up $m$  in $S$ with respect to $L$. Otherwise, we say that the method lookup has failed.
 
 \rationale {
-The motivation for skipping abstract members during lookup is largely to allow smoother mixin composition. 
+The motivation for skipping abstract members during lookup is largely to allow smoother mixin composition.
 }
 
 
@@ -3754,7 +3762,7 @@ The result of a lookup of a getter (respectively setter) $m$ in class $C$  with
 If $C$ declares a concrete instance getter (respectively setter) named $m$  that is accessible to $L$,  then that getter (respectively setter) is the result of the lookup, and we say that the getter (respectively setter) was {\em looked up in $C$}. Otherwise, if $C$ has a superclass $S$, then the result of the lookup is the result of looking up getter (respectively setter) $m$ in $S$ with respect to $L$. Otherwise, we say that the lookup has failed.
 
 \rationale {
-The motivation for skipping abstract members during lookup is largely to allow smoother mixin composition. 
+The motivation for skipping abstract members during lookup is largely to allow smoother mixin composition.
 }
 
 
@@ -3767,7 +3775,7 @@ Evaluation of a top-level getter invocation $i$ of the form $m$, where $m$ is an
 \LMHash{}
 The getter function $m$ is invoked. The value of $i$ is the result returned by the call to the getter function.
 \commentary{
-Note that the invocation is always defined. Per the rules for identifier references, an identifier will not be treated as a top-level getter invocation unless the getter $i$ is defined. 
+Note that the invocation is always defined. Per the rules for identifier references, an identifier will not be treated as a top-level getter invocation unless the getter $i$ is defined.
 }
 
 \LMHash{}
@@ -3777,7 +3785,7 @@ The static type of $i$ is the declared return type of $m$.
 \LMLabel{methodInvocation}
 
 \LMHash{}
-Method invocation can take several forms as specified below. 
+Method invocation can take several forms as specified below.
 
 \subsubsection{Ordinary Invocation}
 \LMLabel{ordinaryInvocation}
@@ -3786,16 +3794,16 @@ Method invocation can take several forms as specified below.
 An ordinary method invocation can be {\em conditional} or {\em unconditional}.
 
 \LMHash{}
-Evaluation of a {\em conditional ordinary method invocation} $e$ of the form 
+Evaluation of a {\em conditional ordinary method invocation} $e$ of the form
 
 \LMHash{}
-$o?.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$  
+$o?.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$
 
 \LMHash{}
-is equivalent to the evaluation of the expression  
+is equivalent to the evaluation of the expression
 
 \LMHash{}
-$((x) => x == \NULL ? \NULL : x.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k}))(o)$. 
+$((x) => x == \NULL ? \NULL : x.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k}))(o)$.
 
 unless $o$ is  a type literal, in which case it is equivalent to $o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 
@@ -3803,25 +3811,25 @@ unless $o$ is  a type literal, in which case it is equivalent to $o.m(a_1, \ldot
 The static type of $e$ is the same as the static type of $o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$. Exactly the same static warnings that would be caused by $o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ are also generated in the case of $o?.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 
 \LMHash{}
-An {\em unconditional ordinary method invocation} $i$ has the form 
+An {\em unconditional ordinary method invocation} $i$ has the form
 
 $o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 
 \LMHash{}
-Evaluation of an unconditional ordinary method invocation $i$ of the form 
+Evaluation of an unconditional ordinary method invocation $i$ of the form
 
-$o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ 
+$o.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$
 
 proceeds as follows:
 
 \LMHash{}
-First, the expression $o$ is evaluated to a value $v_o$. Next, the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ is evaluated yielding actual argument objects $o_1, \ldots , o_{n+k}$. Let $f$ be the result of looking up (\ref{methodLookup}) method $m$  in $v_o$ with respect to the current library $L$. 
+First, the expression $o$ is evaluated to a value $v_o$. Next, the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ is evaluated yielding actual argument objects $o_1, \ldots , o_{n+k}$. Let $f$ be the result of looking up (\ref{methodLookup}) method $m$  in $v_o$ with respect to the current library $L$.
 
 \LMHash{}
 Let $p_1 \ldots p_h$ be the required parameters of $f$,  let $p_1 \ldots p_m$ be the positional parameters of $f$ and let $p_{h+1}, \ldots, p_{h+l}$ be the optional parameters declared by $f$.
 
 \commentary{
-We have an argument list consisting of $n$ positional arguments and $k$ named arguments. We have a function with $h$ required parameters and $l$ optional parameters. The number of positional arguments must be at least as large as the number of required parameters, and no larger than the number of positional parameters. All named arguments must have a corresponding named parameter. 
+We have an argument list consisting of $n$ positional arguments and $k$ named arguments. We have a function with $h$ required parameters and $l$ optional parameters. The number of positional arguments must be at least as large as the number of required parameters, and no larger than the number of positional parameters. All named arguments must have a corresponding named parameter.
 }
 
 \LMHash{}
@@ -3831,9 +3839,9 @@ If  $n < h$, or $n > m$, the method lookup has failed. Furthermore, each $x_i, n
 If the method lookup succeeded, the body of $f$ is executed with respect to the bindings that resulted from the evaluation of the argument list, and with \THIS{} bound to $v_o$. The value of $i$ is the value returned after $f$ is executed.
 
 \LMHash{}
-If the method lookup has failed, then let $g$ be the result of looking up getter (\ref{getterAndSetterLookup}) $m$ in $v_o$ with respect to $L$. 
+If the method lookup has failed, then let $g$ be the result of looking up getter (\ref{getterAndSetterLookup}) $m$ in $v_o$ with respect to $L$.
 If $v_o$ is an instance of \code{Type} but $o$ is not a constant type literal, then if $g$ is a getter that forwards to a static getter, getter lookup fails.
-If the getter lookup succeeded, let $v_g$ be the value of the getter invocation $o.m$. Then the value of $i$ is the result of invoking 
+If the getter lookup succeeded, let $v_g$ be the value of the getter invocation $o.m$. Then the value of $i$ is the result of invoking
 the static method \code{Function.apply()} with arguments $v.g, [o_1, \ldots , o_n], \{x_{n+1}: o_{n+1}, \ldots , x_{n+k}: o_{n+k}\}$.
 
 \LMHash{}
@@ -3864,7 +3872,7 @@ It is possible to bring about such a situation by overriding \code{noSuchMethod(
     noSuchMethod(x,y) =$>$ x + y;
 \}
 
-\NEW{} Perverse.unknownMethod(); 
+\NEW{} Perverse.unknownMethod();
 \end{code}
 
 \commentary{Notice that the wording carefully avoids re-evaluating the receiver $o$ and the arguments $a_i$. }
@@ -3875,12 +3883,12 @@ Let $T$ be the  static type of $o$. It is a static type warning if $T$ does not
 \item
 $T$ or a superinterface of $T$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}.  Or
 \item  $T$ is \code{Type}, $e$ is a constant type literal and the class corresponding to $e$ has a static getter named $m$.
-\item $T$ is \code{Function} and $m$ is \CALL. \rationale {The type \code{Function} is treated as if it has a \code{call} method for any possible signature of \CALL. The expectation is that any concrete subclass of \code{Function} will implement \CALL. Note that a warning will be issue if this is not the case. Furthermore, any use of \CALL{} on a subclass of \code{Function} that fails to implement \CALL{} will also provoke a a warning, as this exemption is limited to type \code{Function}, and does not apply to its subtypes. 
+\item $T$ is \code{Function} and $m$ is \CALL. \rationale {The type \code{Function} is treated as if it has a \code{call} method for any possible signature of \CALL. The expectation is that any concrete subclass of \code{Function} will implement \CALL. Note that a warning will be issue if this is not the case. Furthermore, any use of \CALL{} on a subclass of \code{Function} that fails to implement \CALL{} will also provoke a warning, as this exemption is limited to type \code{Function}, and does not apply to its subtypes.
 }
 \end{itemize}
 
 \LMHash{}
-If $T.m$ exists, it  is a static type warning if the type $F$ of $T.m$ may not be assigned to a function type. If $T.m$ does not exist, or if $F$ is not a function type, the static type of $i$ is \DYNAMIC{}; otherwise the static type of $i$ is the declared return type of  $F$.  
+If $T.m$ exists, it  is a static type warning if the type $F$ of $T.m$ may not be assigned to a function type. If $T.m$ does not exist, or if $F$ is not a function type, the static type of $i$ is \DYNAMIC{}; otherwise the static type of $i$ is the declared return type of  $F$.
 
 \LMHash{}
 It is a compile-time error to invoke any of the methods of class \cd{Object} on a prefix object (\ref{imports}) or on a constant type literal that is  immediately followed by the token `.'.
@@ -3897,7 +3905,7 @@ where $e$ is an expression and {\em suffix} is a sequence of operator, method, g
 {\bf cascadeSection:}
       `{\escapegrammar ..}' (cascadeSelector arguments*) (assignableSelector arguments*)* (assignmentOperator expressionWithoutCascade)?
       .
-     
+
 {\bf cascadeSelector:}`['  expression `]';
       identifier
       .
@@ -3916,7 +3924,7 @@ The present specification has not added such a construct, in the interests of si
 \LMLabel{superInvocation}
 
 \LMHash{}
-A super method invocation $i$ has the form 
+A super method invocation $i$ has the form
 
 $\SUPER{}.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 
@@ -3924,7 +3932,7 @@ $\SUPER{}.m(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$.
 Evaluation of $i$ proceeds as follows:
 
 \LMHash{}
-First, the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ is evaluated  yielding actual argument objects $o_1, \ldots , o_{n+k}$. Let $g$ be the method currently executing, and let $C$ be the class in which $g$ was looked up (\ref{methodLookup}). Let $S_{dynamic}$ be the superclass of $C$, and let $f$ be the result of looking up method (\ref{methodLookup})  $m$ in $S_{dynamic}$  with respect to the current library $L$. 
+First, the argument list $(a_1, \ldots , a_n, x_{n+1}: a_{n+1}, \ldots , x_{n+k}: a_{n+k})$ is evaluated  yielding actual argument objects $o_1, \ldots , o_{n+k}$. Let $g$ be the method currently executing, and let $C$ be the class in which $g$ was looked up (\ref{methodLookup}). Let $S_{dynamic}$ be the superclass of $C$, and let $f$ be the result of looking up method (\ref{methodLookup})  $m$ in $S_{dynamic}$  with respect to the current library $L$.
 Let $p_1 \ldots p_h$ be the required parameters of $f$,  let $p_1 \ldots p_m$ be the positional parameters of $f$ and let $p_{h+1}, \ldots, p_{h+l}$ be the optional parameters declared by $f$.
 
 \LMHash{}
@@ -3934,9 +3942,9 @@ If  $n < h$, or $n > m$, the method lookup has failed. Furthermore, each $x_i, n
 If the method lookup succeeded, the body of $f$ is executed with respect to the bindings that resulted from the evaluation of the argument list, and with \THIS{} bound to the current value of \THIS{}. The value of $i$ is the value returned after $f$ is executed.
 
 \LMHash{}
-If the method lookup has failed, then let $g$ be the result of looking up getter (\ref{getterAndSetterLookup}) $m$ in $S_{dynamic}$ with respect to $L$. If the getter lookup succeeded, let $v_g$ be the value of the getter invocation $\SUPER{}.m$. Then the value of $i$ is the result of invoking 
+If the method lookup has failed, then let $g$ be the result of looking up getter (\ref{getterAndSetterLookup}) $m$ in $S_{dynamic}$ with respect to $L$. If the getter lookup succeeded, let $v_g$ be the value of the getter invocation $\SUPER{}.m$. Then the value of $i$ is the result of invoking
 the static method \code{Function.apply()} with arguments $v_g, [o_1, \ldots , o_n], \{x_{n+1}: o_{n+1}, \ldots , x_{n+k}: o_{n+k}\}$.
- 
+
 \LMHash{}
 If  getter lookup has also failed, then a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
 \begin{itemize}
@@ -3960,7 +3968,7 @@ and the result of this latter invocation is the result of evaluating $i$.
 It is a compile-time error if a super method invocation occurs in a top-level function or variable initializer, in an instance variable initializer or initializer list, in class \code{Object}, in a factory constructor or in a static method or variable initializer.
 
 \LMHash{}
-Let $S_{static}$ be the superclass of the immediately enclosing class. It is a static type warning if $S_{static}$ does not have an accessible (\ref{privacy}) instance member named $m$ unless $S_{static}$ or a superinterface of $S_{static}$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}. If $S_{static}.m$ exists, it  is a static type warning if the type $F$ of $S_{static}.m$ may not be assigned to a function type. If $S_{static}.m$ does not exist, or if $F$ is not a function type, the static type of $i$ is \DYNAMIC{}; otherwise the static type of $i$ is the declared return type of  $F$.  
+Let $S_{static}$ be the superclass of the immediately enclosing class. It is a static type warning if $S_{static}$ does not have an accessible (\ref{privacy}) instance member named $m$ unless $S_{static}$ or a superinterface of $S_{static}$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}. If $S_{static}.m$ exists, it  is a static type warning if the type $F$ of $S_{static}.m$ may not be assigned to a function type. If $S_{static}.m$ does not exist, or if $F$ is not a function type, the static type of $i$ is \DYNAMIC{}; otherwise the static type of $i$ is the declared return type of  $F$.
 % The following is not needed because it is specified in 'Binding Actuals to Formals"
 %Let $T_i$ be the static type of $a_i, i \in 1 .. n+k$. It is a static warning if $F$ is not a supertype of  $(T_1, \ldots, t_n, \{T_{n+1}$ $x_{n+1}, \ldots, T_{n+k}$ $x_{n+k}\}) \to \bot$.
 
@@ -3971,7 +3979,7 @@ Let $S_{static}$ be the superclass of the immediately enclosing class. It is a s
 \LMLabel{sendingMessages}
 
 \LMHash{}
-Messages are the sole means of communication among isolates. Messages are sent by invoking specific  methods in the Dart libraries; there is no specific syntax for sending a message. 
+Messages are the sole means of communication among isolates. Messages are sent by invoking specific  methods in the Dart libraries; there is no specific syntax for sending a message.
 
 \commentary{In other words, the methods supporting sending messages embody primitives of Dart that are not accessible to ordinary code, much like the methods that spawn isolates.
 }
@@ -3998,7 +4006,7 @@ Property extraction can be either {\em conditional} or {\em unconditional}.
 Tear-offs using the \cd{ x\#id}  syntax cannot be conditional at this time; this is inconsistent, and is likely to be addressed in the near future, perhaps via  notation such as  \cd{ x?\#id} . As indicated in section \ref{ecmaConformance}, experimentation in this area is allowed.
 }
 
-Evaluation of a {\em conditional property extraction expression} $e$ of the form $e_1?.id$  is equivalent to the evaluation of the expression  $((x) => x == \NULL ? \NULL : x.id)(e_1)$. 
+Evaluation of a {\em conditional property extraction expression} $e$ of the form $e_1?.id$  is equivalent to the evaluation of the expression  $((x) => x == \NULL ? \NULL : x.id)(e_1)$.
 unless $e_1$ is  a type literal, in which case it is equivalent to $e_1.m$.
 
 The static type of $e$ is the same as the static type of $e_1.id$. Let $T$ be the static type of $e_1$ and let $y$ be a fresh variable of type $T$. Exactly the same static warnings that would be caused by $y.id$ are also generated in the case of $e_1?.id$.
@@ -4013,7 +4021,7 @@ Unconditional property extraction takes several syntactic forms: $e.m$ (\ref{get
 Evaluation of a property extraction $i$ of the form $e.m$ proceeds as follows:
 
 \LMHash{}
-First, the expression $e$ is evaluated to an object $o$. Let $f$ be the result of looking up (\ref{methodLookup}) method  (\ref{instanceMethods}) $m$ in $o$ with respect to the current library $L$.  If $o$ is an instance of \code{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards (\ref{functionDeclarations}) to a static method,  method lookup fails. If method lookup succeeds then $i$ evaluates to the closurization of method $f$ on object $o$ (\ref{ordinaryMemberClosurization}).  
+First, the expression $e$ is evaluated to an object $o$. Let $f$ be the result of looking up (\ref{methodLookup}) method  (\ref{instanceMethods}) $m$ in $o$ with respect to the current library $L$.  If $o$ is an instance of \code{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards (\ref{functionDeclarations}) to a static method,  method lookup fails. If method lookup succeeds then $i$ evaluates to the closurization of method $f$ on object $o$ (\ref{ordinaryMemberClosurization}).
 
 \commentary {
 Note that $f$ is never an abstract method, because method lookup skips abstract methods. Hence, if $m$ refers to an abstract method, we will continue to the next step. However, since methods and getters never override each other, getter lookup will necessarily fail as well, and \cd{noSuchMethod()} will ultimately be invoked. The regrettable implication is that the error will refer to a missing getter rather than an attempt to closurize an abstract method.
@@ -4021,7 +4029,7 @@ Note that $f$ is never an abstract method, because method lookup skips abstract
 
 \LMHash{}
 Otherwise, $i$ is a getter invocation.  Let $f$ be the result of looking up
-(\ref{getterAndSetterLookup}) getter (\ref{getters}) $m$ in $o$  with respect to $L$. If $o$ is an instance of \code{Type} but $e$ is not a constant type literal, then if $f$ is a getter that forwards  to a static getter,  getter lookup fails. Otherwise, the body of $f$ is executed with \THIS{} bound to $o$.  The value of $i$ is the result returned by the call to the getter function. 
+(\ref{getterAndSetterLookup}) getter (\ref{getters}) $m$ in $o$  with respect to $L$. If $o$ is an instance of \code{Type} but $e$ is not a constant type literal, then if $f$ is a getter that forwards  to a static getter,  getter lookup fails. Otherwise, the body of $f$ is executed with \THIS{} bound to $o$.  The value of $i$ is the result returned by the call to the getter function.
 
 \LMHash{}
 If the getter lookup has failed, then a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
@@ -4063,7 +4071,7 @@ The static type of $i$ is:
 \item The declared return type of $m$, if  $T$ is \code{Type}, $e$ is a constant type literal and the class corresponding to $e$ declares an accessible static getter named $m$.
 \item The static type of function $T.m$ if $T$ has an accessible instance method named $m$.
 \item The static type of function $m$, if  $T$ is \code{Type}, $e$ is a constant type literal and the class corresponding to $e$ declares an accessible static method named $m$.
-\item  The type \DYNAMIC{} otherwise.  
+\item  The type \DYNAMIC{} otherwise.
 \end{itemize}
 
 
@@ -4074,10 +4082,10 @@ The static type of $i$ is:
 Evaluation of a property extraction $i$ of the form $\SUPER.m$ proceeds as follows:
 
 \LMHash{}
-Let $g$ be the method currently executing, and let $C$ be the class in which $g$ was looked up.  Let $S_{dynamic}$ be the superclass of $C$. Let $f$ be the result of looking up method $m$ in $S_{dynamic}$ with respect to the current library $L$.  If method lookup succeeds then $i$ evaluates to the closurization of method $f$ with respect to superclass $S_{dynamic}$ (\ref{superClosurization}).  
- 
+Let $g$ be the method currently executing, and let $C$ be the class in which $g$ was looked up.  Let $S_{dynamic}$ be the superclass of $C$. Let $f$ be the result of looking up method $m$ in $S_{dynamic}$ with respect to the current library $L$.  If method lookup succeeds then $i$ evaluates to the closurization of method $f$ with respect to superclass $S_{dynamic}$ (\ref{superClosurization}).
+
 \LMHash{}
- Otherwise, $i$ is a getter invocation.  Let $f$ be the result of  looking up getter $m$ in $S_{dynamic}$  with respect to $L$.  The body of $f$  is executed with \THIS{} bound to the current value of  \THIS{}.  The value of $i$ is the result returned by the call to the getter function. 
+ Otherwise, $i$ is a getter invocation.  Let $f$ be the result of  looking up getter $m$ in $S_{dynamic}$  with respect to $L$.  The body of $f$  is executed with \THIS{} bound to the current value of  \THIS{}.  The value of $i$ is the result returned by the call to the getter function.
 
 \LMHash{}
 If the getter lookup has failed, then a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
@@ -4097,13 +4105,13 @@ Then the method \code{noSuchMethod()} is looked up in $S_{dynamic}$ and invoked
 and the result of this latter invocation is the result of evaluating $i$.
 
 \LMHash{}
-Let $S_{static}$ be the superclass of the immediately enclosing class. It is a static type warning if $S_{static}$ does not have an accessible instance method or getter named $m$.  
+Let $S_{static}$ be the superclass of the immediately enclosing class. It is a static type warning if $S_{static}$ does not have an accessible instance method or getter named $m$.
 
 The static type of $i$ is:
 \begin{itemize}
 \item The declared return type of $S_{static}.m$, if $S_{static}$ has an accessible instance getter named $m$.
 \item The static type of function $S_{static}.m$ if $S_{static}$ has an accessible instance method named $m$.
-\item The type  \DYNAMIC{} otherwise. 
+\item The type  \DYNAMIC{} otherwise.
 \end{itemize}
 
 
@@ -4117,23 +4125,23 @@ Evaluation of a property extraction $i$ of the form $e\#m$ proceeds as follows:
 First, the expression $e$ is evaluated to an object $o$.  Then:
 
 \LMHash{}
- if $m$ is a setter name, let $f$ be the result of looking up setter $m$ in $o$ with respect to the current library $L$.   If $o$ is an instance of \cd{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards to a static setter, setter lookup fails. If setter lookup succeeds then $i$ evaluates to the closurization of setter $f$ on object $o$ (\ref{ordinaryMemberClosurization}). 
+ if $m$ is a setter name, let $f$ be the result of looking up setter $m$ in $o$ with respect to the current library $L$.   If $o$ is an instance of \cd{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards to a static setter, setter lookup fails. If setter lookup succeeds then $i$ evaluates to the closurization of setter $f$ on object $o$ (\ref{ordinaryMemberClosurization}).
  If setter lookup failed, a \cd{NoSuchMethodError} is thrown.
- 
+
   \rationale {
 It would be more in keeping with the rules of Dart to invoke \cd{noSuchMethod} in this and similar cases below. However,  current implementations of \cd{noSuchMethod} cannot distinguish between an invocation of a closurization and an actual call.  It is likely that future versions of Dart will provide a mechanism to detect whether \cd{noSuchMethod} is invoked in response to a closurization, say by means of a getter like \cd{isTearOff}. By being conservative at this stage and insisting on failure, we can ensure that no functioning code will break when/if this functionality is introduced.
  }
 
- 
+
  \LMHash{}
-If $m$ is not a setter name, let $f$ be the result of looking up method $m$ in $o$ with respect to the current library $L$.   If $o$ is an instance of \cd{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards to a static method, method lookup fails. If method lookup succeeds then $i$ evaluates to the closurization of method $f$ on object $o$ (\ref{ordinaryMemberClosurization}).  
- 
+If $m$ is not a setter name, let $f$ be the result of looking up method $m$ in $o$ with respect to the current library $L$.   If $o$ is an instance of \cd{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards to a static method, method lookup fails. If method lookup succeeds then $i$ evaluates to the closurization of method $f$ on object $o$ (\ref{ordinaryMemberClosurization}).
+
 \LMHash{}
-If method lookup failed, let $f$ be the result of looking up getter $m$ in $o$ with respect to the current library $L$.   If $o$ is an instance of \cd{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards to a static getter, getter lookup fails. If getter lookup succeeds then $i$ evaluates to the closurization of getter $f$ on object $o$ (\ref{ordinaryMemberClosurization}).  
+If method lookup failed, let $f$ be the result of looking up getter $m$ in $o$ with respect to the current library $L$.   If $o$ is an instance of \cd{Type} but $e$ is not a constant type literal, then if $f$ is a method that forwards to a static getter, getter lookup fails. If getter lookup succeeds then $i$ evaluates to the closurization of getter $f$ on object $o$ (\ref{ordinaryMemberClosurization}).
  If getter lookup failed, a \cd{NoSuchMethodError} is thrown.
- 
-  
- 
+
+
+
 
 %\LMHash{}
 %Otherwise,  a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
@@ -4153,7 +4161,7 @@ If method lookup failed, let $f$ be the result of looking up getter $m$ in $o$ w
 %and the result of this latter invocation is the result of evaluating $i$.
 
 \LMHash{}
-It is a compile-time error if $e$ is a prefix object (\ref{imports}) and $m$ refers to a type or a member of class \cd{Object}.
+It is a compile-time error if $e$ is a prefix object, $p$, (\ref{imports}) and $m$ refers to a type accessible via $p$ or to a member of class \cd{Object}.
 
 \commentary{
 This restriction is in line with other limitations on the use of prefixes as objects. The only permitted uses of $p\#m$ are closurizing top level methods and getters imported via the prefix $p$. Top level methods are directly available by their qualified names: $p.m$. However, getters and setters are not, and allowing their closurization is the whole point of the $e\#m$ syntax.
@@ -4172,7 +4180,7 @@ The static type of $i$ is:
 \item The static type of function $T.m$, if $T$ has an accessible instance member named $m$.
 \item The static type of function $T.m$, if $T$ is \cd{Type}, $e$ is a constant type literal and the class corresponding to $e$ declares an accessible static member or constructor named $m$.
 \item \code{Function} if $T$ is \code{Function} and $m$ is \CALL.
-\item The type  \DYNAMIC{} otherwise. 
+\item The type  \DYNAMIC{} otherwise.
 \end{itemize}
 
 \subsubsection{Named Constructor Extraction}
@@ -4189,6 +4197,8 @@ If $T$ is a malformed type (\ref{staticTypes}), a dynamic error occurs. If $T$ i
 \LMHash{}
 The static type of $i$ is the type of the constructor function, if $T$ denotes a class in the surrounding scope with an accessible constructor $f$ named $m$. Otherwise the static type of $i$ is \DYNAMIC{}.
 
+It is a compile-time error if $T$ is an enumerated type (\ref{enums}).
+
 \subsubsection{Anonymous Constructor Extraction}
 \LMLabel{anonymousConstructorExtraction}
 
@@ -4203,6 +4213,9 @@ If $T$ is a malformed type (\ref{staticTypes}), a dynamic error occurs. If $T$ i
 \LMHash{}
 The static type of $i$ is the type of the constructor function $T()$, if $T$ denotes a class in the surrounding scope with an anonymous constructor $T()$. Otherwise the static type of $i$ is \DYNAMIC{}.
 
+It is a compile-time error if $T$ is an enumerated type (\ref{enums}).
+
+
 \subsubsection{General Super Property Extraction}
 \LMLabel{generalSuperPropertyExtraction}
 
@@ -4211,7 +4224,7 @@ The static type of $i$ is the type of the constructor function $T()$, if $T$ den
 Evaluation of a property extraction $i$ of the form \SUPER$\#m$ proceeds as follows:
 
  \LMHash{}
-Let $g$ be the method currently executing, and let $C$ be the class in which $g$ was looked up.  Let $S_{dynamic}$ be the superclass of $C$. 
+Let $g$ be the method currently executing, and let $C$ be the class in which $g$ was looked up.  Let $S_{dynamic}$ be the superclass of $C$.
 
  \LMHash{}
 If $m$ is a setter name, let $f$ be the result of looking up setter $m$ in $S_{dynamic}$ with respect to the current library $L$. If setter lookup succeeds then $i$ evaluates to the closurization of setter $f$  with respect to superclass $S_{dynamic}$  (\ref{superClosurization}).  If setter lookup failed, a \cd{NoSuchMethodError} is thrown.
@@ -4241,14 +4254,14 @@ The {\em closurization of method $f$ on object $o$} is defined to be equivalent
 \item $() \{\RETURN{}$ \~{} $u;$\} if $f$ is named \~{}.
 \item $(a) \{\RETURN{}$ $u[a];$\} if $f$ is named $[]$.
 \item $(a, b) \{\RETURN{}$ $u[a] = b;$\} if $f$ is named $[]=$.
-\item  
+\item
 \begin{dartCode}
 $(r_1, \ldots, r_n, \{p_1 : d_1, \ldots , p_k : d_k\})$ \{
   \RETURN{} $ u.m(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k);$
-\} 
+\}
 \end{dartCode}
 if $f$ is named $m$ and has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
-\item 
+\item
 \begin{dartCode}
 $(r_1, \ldots, r_n, [p_1 = d_1, \ldots , p_k = d_k])$\{
   \RETURN{} $u.m(r_1, \ldots, r_n, p_1, \ldots, p_k)$;
@@ -4291,15 +4304,15 @@ One cannot closurize a constructor, getter or a setter via the dot based syntax.
 \LMHash{}
 The {\em closurization of constructor $f$ of type $T$} is defined to be equivalent to:
 \begin{itemize}
-\item  
+\item
 \begin{dartCode}
 $(r_1, \ldots, r_n, \{p_1 : d_1, \ldots , p_k : d_k\})$ \{
   \RETURN{} \NEW{} $T.m(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k);$
-\} 
+\}
 \end{dartCode}
 
 if $f$ is a named constructor with name $m$ that has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
-\item 
+\item
 \begin{dartCode}
 $(r_1, \ldots, r_n, [p_1 = d_1, \ldots , p_k = d_k])$\{
   \RETURN{} \NEW{} $T.m(r_1, \ldots, r_n, p_1, \ldots, p_k)$;
@@ -4312,7 +4325,7 @@ if $f$ is a named constructor with name $m$ that has required parameters $r_1, \
 \LMHash{}
 Except that iff  \code{identical($T_1, T_2$)}  then  \cd{\NEW{} $T_1\#m$ == \NEW{} $T_2\#m$}.
 
-\commentary{ 
+\commentary{
 The above implies that for non-parameterized types, one can rely on the equality of closures resulting from closurization on the ``same'' type. For parameterized types, one cannot, since there is no requirement to canonicalize them.
 }
 
@@ -4322,15 +4335,15 @@ The above implies that for non-parameterized types, one can rely on the equality
 \LMHash{}
 The {\em closurization of anonymous constructor $f$ of type $T$} is defined to be equivalent to:
 \begin{itemize}
-\item  
+\item
 \begin{dartCode}
 $(r_1, \ldots, r_n, \{p_1 : d_1, \ldots , p_k : d_k\})$ \{
   \RETURN{} \NEW{} $T(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k);$
-\} 
+\}
 \end{dartCode}
 
 if $f$ is an anonymous constructor that has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
-\item 
+\item
 \begin{dartCode}
 $(r_1, \ldots, r_n, [p_1 = d_1, \ldots , p_k = d_k])$\{
   \RETURN{} \NEW{} $T(r_1, \ldots, r_n, p_1, \ldots, p_k)$;
@@ -4356,14 +4369,14 @@ The {\em closurization of method $f$ with respect to superclass $S$} is defined
 \item $() \{\RETURN{}$ \~{}\SUPER;\} if $f$ is named \~{}.
 \item $(a) \{\RETURN{}$ $\SUPER[a];$\} if $f$ is named $[]$.
 \item $(a, b) \{\RETURN{}$ $\SUPER[a] = b;$\} if $f$ is named $[]=$.
-\item  
+\item
 \begin{dartCode}
 $(r_1, \ldots, r_n, \{p_1 : d_1, \ldots , p_k : d_k\})$ \{
   \RETURN{} \SUPER$.m(r_1, \ldots, r_n, p_1: p_1, \ldots, p_k: p_k);$
-\} 
+\}
 \end{dartCode}
 if $f$ is named $m$ and has required parameters $r_1, \ldots, r_n$, and named parameters $p_1, \ldots, p_k$ with defaults $d_1, \ldots, d_k$.
-\item 
+\item
 \begin{dartCode}
 $(r_1, \ldots, r_n, [p_1 = d_1, \ldots , p_k = d_k])$\{
   \RETURN{} \SUPER$.m(r_1, \ldots, r_n, p_1, \ldots, p_k)$;
@@ -4403,11 +4416,11 @@ Evaluation of an assignment $a$ of the form $v$ \code{=} $e$ proceeds as follows
 
 %If there is neither a local variable declaration with name $v$ nor a setter declaration with name $v=$ in the lexical scope enclosing $a$, then:
 %\begin{itemize}
-% \item If  $a$ occurs inside a top level or static function (be it function, method, getter,  or setter) or variable initializer, evaluation of $a$ causes $e$ to be evaluated, after which a \code{NoSuchMethodError} is thrown. 
-% \item Otherwise, the assignment is equivalent to the assignment \code{ \THIS{}.$v$ = $e$}. 
+% \item If  $a$ occurs inside a top level or static function (be it function, method, getter,  or setter) or variable initializer, evaluation of $a$ causes $e$ to be evaluated, after which a \code{NoSuchMethodError} is thrown.
+% \item Otherwise, the assignment is equivalent to the assignment \code{ \THIS{}.$v$ = $e$}.
 % \end{itemize}
- 
-%Otherwise 
+
+%Otherwise
 
 \LMHash{}
 Let $d$ be the innermost declaration whose name is $v$ or $v=$, if it exists.
@@ -4415,21 +4428,21 @@ It is a compile-time error if $d$ denotes a prefix object.
 
 \LMHash{}
 If $d$ is the declaration of a local variable, the expression $e$ is evaluated to an object $o$. Then, the variable $v$ is bound to $o$ unless $v$ is \FINAL{} or \CONST{}, in which case a dynamic error occurs.
-If no error occurs, the value of the assignment expression is $o$.  
+If no error occurs, the value of the assignment expression is $o$.
 
 % add local functions per bug 23218
 
 \LMHash{}
-If $d$ is the declaration of a library variable, top level getter or top level setter, the expression $e$ is evaluated to an object $o$. Then the setter $v=$ is invoked with its formal parameter bound to $o$. The value of the assignment expression is $o$.  
+If $d$ is the declaration of a library variable, top level getter or top level setter, the expression $e$ is evaluated to an object $o$. Then the setter $v=$ is invoked with its formal parameter bound to $o$. The value of the assignment expression is $o$.
 
 \LMHash{}
 Otherwise, if $d$ is the declaration of a static variable, static getter or static setter in class $C$, then the assignment is equivalent to the assignment \code{$C.v$ = $e$}.
 
 \LMHash{}
-Otherwise, If  $a$ occurs inside a top level or static function (be it function, method, getter,  or setter) or variable initializer, evaluation of $a$ causes $e$ to be evaluated, after which a \code{NoSuchMethodError} is thrown. 
+Otherwise, If  $a$ occurs inside a top level or static function (be it function, method, getter,  or setter) or variable initializer, evaluation of $a$ causes $e$ to be evaluated, after which a \code{NoSuchMethodError} is thrown.
 
 \LMHash{}
-Otherwise, the assignment is equivalent to the assignment \code{ \THIS{}.$v$ = $e$}. 
+Otherwise, the assignment is equivalent to the assignment \code{ \THIS{}.$v$ = $e$}.
 
 \LMHash{}
 In checked mode, it is a dynamic type error if $o$ is not \NULL{} and the interface of the class of $o$ is not a subtype of the actual type (\ref{actualTypeOfADeclaration}) of $v$.
@@ -4446,7 +4459,7 @@ Evaluation of an assignment $a$ of the form $e_1?.v$ \code{=} $e_2$ is equivalen
 Evaluation of an assignment of the form $e_1.v$ \code{=} $e_2$ proceeds as follows:
 
 \LMHash{}
-The expression $e_1$ is evaluated to an object $o_1$. Then, the expression $e_2$  is evaluated to an object $o_2$. Then, the setter $v=$ is looked up (\ref{getterAndSetterLookup}) in $o_1$ with respect to the current library.  If $o_1$ is an instance of \code{Type} but $e_1$ is not a constant type literal, then if $v=$ is a setter that forwards (\ref{functionDeclarations}) to a static setter, setter lookup fails. Otherwise, the body  of $v=$ is executed with its formal parameter bound to $o_2$ and \THIS{} bound to $o_1$. 
+The expression $e_1$ is evaluated to an object $o_1$. Then, the expression $e_2$  is evaluated to an object $o_2$. Then, the setter $v=$ is looked up (\ref{getterAndSetterLookup}) in $o_1$ with respect to the current library.  If $o_1$ is an instance of \code{Type} but $e_1$ is not a constant type literal, then if $v=$ is a setter that forwards (\ref{functionDeclarations}) to a static setter, setter lookup fails. Otherwise, the body  of $v=$ is executed with its formal parameter bound to $o_2$ and \THIS{} bound to $o_1$.
 
 \LMHash{}
 If the setter lookup has failed, then a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
@@ -4458,7 +4471,7 @@ If the setter lookup has failed, then a new instance $im$  of the predefined cla
 \end{itemize}
 
 \LMHash{}
-Then the method \code{noSuchMethod()} is looked up in $o_1$ and invoked  with argument $im$. 
+Then the method \code{noSuchMethod()} is looked up in $o_1$ and invoked  with argument $im$.
 However, if the implementation found cannot be invoked with a single positional argument, the implementation  of \code{noSuchMethod()} in class \code{Object} is invoked on $o_1$ with argument $im'$, where $im'$ is an instance of \code{Invocation} such that :
 \begin{itemize}
 \item  \code{im'.isMethod} evaluates to \code{\TRUE{}}.
@@ -4477,7 +4490,7 @@ In checked mode, it is a dynamic type error if $o_2$ is not \NULL{} and the inte
 Let $T$ be the static type of $e_1$. It is a static type warning if $T$ does not have an accessible instance setter named $v=$ unless either:
 \begin{itemize}
 \item $T$ or a superinterface of $T$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}. Or
-\item $T$ is \code{Type}, $e_1$ is a constant type literal and the class corresponding to $e_1$ has a static setter named $v=$. 
+\item $T$ is \code{Type}, $e_1$ is a constant type literal and the class corresponding to $e_1$ has a static setter named $v=$.
 \end{itemize}
 
 
@@ -4489,8 +4502,8 @@ It is a static type warning if the static type of $e_2$ may not be assigned to t
 Evaluation of an assignment of the form $\SUPER.v$ \code{=} $e$ proceeds as follows:
 
 \LMHash{}
-Let $g$ be the method currently executing, and let $C$ be the class in which $g$ was looked up.  Let $S_{dynamic}$ be the superclass of $C$. 
-The expression $e$ is evaluated to an object $o$.  Then, the setter $v=$ is looked up (\ref{getterAndSetterLookup}) in $S_{dynamic}$ with respect to the current library.  The body  of $v=$ is executed with its formal parameter bound to $o$ and \THIS{} bound to \THIS{}. 
+Let $g$ be the method currently executing, and let $C$ be the class in which $g$ was looked up.  Let $S_{dynamic}$ be the superclass of $C$.
+The expression $e$ is evaluated to an object $o$.  Then, the setter $v=$ is looked up (\ref{getterAndSetterLookup}) in $S_{dynamic}$ with respect to the current library.  The body  of $v=$ is executed with its formal parameter bound to $o$ and \THIS{} bound to \THIS{}.
 
 \LMHash{}
 If the setter lookup has failed, then a new instance $im$  of the predefined class  \code{Invocation}  is created, such that :
@@ -4502,7 +4515,7 @@ If the setter lookup has failed, then a new instance $im$  of the predefined cla
 \end{itemize}
 
 \LMHash{}
-Then the method \code{noSuchMethod()} is looked up in $S_{dynamic}$ and invoked  with argument $im$. 
+Then the method \code{noSuchMethod()} is looked up in $S_{dynamic}$ and invoked  with argument $im$.
 However, if the implementation found cannot be invoked with a single positional argument, the implementation  of \code{noSuchMethod()} in class \code{Object} is invoked on \THIS{} with argument $im'$, where $im'$ is an instance of \code{Invocation} such that :
 \begin{itemize}
 \item  \code{im'.isMethod} evaluates to \code{\TRUE{}}.
@@ -4518,7 +4531,7 @@ The value of the assignment expression is $o$ irrespective of whether setter loo
 In checked mode, it is a dynamic type error if $o$ is not \NULL{} and the interface of the class of $o$ is not a subtype of the actual type of $S.v$.
 
 \LMHash{}
-Let $S_{static}$ be the superclass of the immediately enclosing class. It is a static type warning if $S_{static}$ does not have an accessible instance setter named $v=$ unless $S_{static}$ or a superinterface of $S_{static}$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}. 
+Let $S_{static}$ be the superclass of the immediately enclosing class. It is a static type warning if $S_{static}$ does not have an accessible instance setter named $v=$ unless $S_{static}$ or a superinterface of $S_{static}$ is annotated with an annotation denoting a constant identical to the constant \code{@proxy} defined in \code{dart:core}.
 
 \LMHash{}
 It is a static type warning if the static type of $e$ may not be assigned to the static type of the formal parameter of the setter $v=$.   The static type of the expression $\SUPER.v$ \code{=} $e$ is the static type of $e$.
@@ -4549,27 +4562,27 @@ It is a compile-time error to invoke any of the setters of class \cd{Object} on
 \LMLabel{compoundAssignment}
 
 \LMHash{}
-Evaluation of a compound assignment of the form $v$ {\em ??=} $e$ is equivalent to the evaluation of the expression  $((x) => x == \NULL{}$ ?  $v=e : x)(v)$ where $x$ is a fresh variable that is not used in $e$. 
+Evaluation of a compound assignment of the form $v$ {\em ??=} $e$ is equivalent to the evaluation of the expression  $((x) => x == \NULL{}$ ?  $v=e : x)(v)$ where $x$ is a fresh variable that is not used in $e$.
 
 \LMHash{}
-Evaluation of a compound assignment of the form $C.v$ {\em ??=} $e$, where $C$ is a type literal, is equivalent to the evaluation of the expression  $((x) => x == \NULL{}$?  $C.v=e: x)(C.v)$ where $x$ is a fresh variable that is not used in $e$. 
+Evaluation of a compound assignment of the form $C.v$ {\em ??=} $e$, where $C$ is a type literal, is equivalent to the evaluation of the expression  $((x) => x == \NULL{}$?  $C.v=e: x)(C.v)$ where $x$ is a fresh variable that is not used in $e$.
 
 \commentary {
 The two rules above also apply when the variable v or the type C is prefixed.
 }
 
 \LMHash{}
-Evaluation of a compound assignment of the form $e_1.v$ {\em ??=} $e_2$ is equivalent to the evaluation of the expression  $((x) =>((y) => y == \NULL{}$ ? $ x.v = e_2: y)(x.v))(e_1)$ where $x$ and $y$ are distinct fresh variables that are not used in $e_2$. 
+Evaluation of a compound assignment of the form $e_1.v$ {\em ??=} $e_2$ is equivalent to the evaluation of the expression  $((x) =>((y) => y == \NULL{}$ ? $ x.v = e_2: y)(x.v))(e_1)$ where $x$ and $y$ are distinct fresh variables that are not used in $e_2$.
 
 \LMHash{}
-Evaluation of a compound assignment of the form  $e_1[e_2]$  {\em ??=} $e_3$ is equivalent to the evaluation of the expression  
-$((a, i) => ((x) => x == \NULL{}$ ?  $a[i] = e_3: x)(a[i]))(e_1, e_2)$ where $x$, $a$ and $i$ are distinct fresh variables that are not used in $e_3$. 
+Evaluation of a compound assignment of the form  $e_1[e_2]$  {\em ??=} $e_3$ is equivalent to the evaluation of the expression
+$((a, i) => ((x) => x == \NULL{}$ ?  $a[i] = e_3: x)(a[i]))(e_1, e_2)$ where $x$, $a$ and $i$ are distinct fresh variables that are not used in $e_3$.
 
 \LMHash{}
 Evaluation of a compound assignment of the form $\SUPER.v$  {\em ??=} $e$ is equivalent to the evaluation of the expression  $((x) => x == \NULL{}$ ? $\SUPER.v = e: x)(\SUPER.v)$ where $x$ is a fresh variable that is not used in $e$.
 
 \LMHash{}
-Evaluation of a compound assignment of the form $e_1?.v$  {\em ??=} $e_2$ is equivalent to the evaluation of the expression \code{((x) $=>$ x == \NULL{} ?  \NULL: $x.v ??=  e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. 
+Evaluation of a compound assignment of the form $e_1?.v$  {\em ??=} $e_2$ is equivalent to the evaluation of the expression \code{((x) $=>$ x == \NULL{} ?  \NULL: $x.v ??=  e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$.
 % But what about C?.v ??= e
 
 \LMHash{}
@@ -4592,15 +4605,15 @@ The static type of a compound assignment of the form $e_1[e_2]$  {\em ??=} $e_3$
 The static type of a compound assignment of the form $\SUPER.v$  {\em ??=} $e$  is the least upper bound of the static type of $\SUPER.v$ and the static type of $e$. Exactly the same static warnings that would be caused by $\SUPER.v = e$ are also generated in the case of $\SUPER.v$  {\em ??=} $e$.
 
 \LMHash{}
-For any other valid operator $op$, a compound assignment of the form $v$ $op\code{=} e$ is equivalent to $v \code{=} v$ $op$ $e$. A compound assignment of the form $C.v$ $op \code{=} e$ is equivalent to $C.v \code{=} C.v$ $op$ $e$. A compound assignment of the form $e_1.v$ $op = e_2$ is equivalent to \code{((x) $=>$ x.v = x.v $op$ $e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. A compound assignment of the form  $e_1[e_2]$ $op\code{=} e_3$ is equivalent to 
-\code{((a, i) $=>$ a[i] = a[i] $op$ $e_3$)($e_1, e_2$)} where $a$ and $i$ are a variables that are not used in $e_3$. 
+For any other valid operator $op$, a compound assignment of the form $v$ $op\code{=} e$ is equivalent to $v \code{=} v$ $op$ $e$. A compound assignment of the form $C.v$ $op \code{=} e$ is equivalent to $C.v \code{=} C.v$ $op$ $e$. A compound assignment of the form $e_1.v$ $op = e_2$ is equivalent to \code{((x) $=>$ x.v = x.v $op$ $e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. A compound assignment of the form  $e_1[e_2]$ $op\code{=} e_3$ is equivalent to
+\code{((a, i) $=>$ a[i] = a[i] $op$ $e_3$)($e_1, e_2$)} where $a$ and $i$ are a variables that are not used in $e_3$.
 
 \LMHash{}
 Evaluation of a compound assignment of the form $e_1?.v$ $op = e_2$ is equivalent to \code{((x) $=>$ x?.v = x.v $op$ $e_2$)($e_1$)} where $x$ is a variable that is not used in $e_2$. The static type of $e_1?.v$ $op = e_2$ is the static type of $e_1.v$ $op$ $e_2$. Exactly the same static warnings that would be caused by $e_1.v$ $op = e_2$ are also generated in the case of $e_1?.v$ $op = e_2$.
 
 \LMHash{}
-A compound assignment of the form $C?.v$ $op = e_2$ is equivalent to the expression 
-$C.v$ $op = e_2$. 
+A compound assignment of the form $C?.v$ $op = e_2$ is equivalent to the expression
+$C.v$ $op = e_2$.
 
 \begin{grammar}
 {\bf compoundAssignmentOperator:}`*=';
@@ -4618,7 +4631,7 @@ $C.v$ $op = e_2$.
     .
 \end{grammar}
 
-    
+
 \subsection{ Conditional}
 \LMLabel{conditional}
 
@@ -4635,7 +4648,7 @@ A {\em conditional expression} evaluates one of two expressions based on a boole
 Evaluation of a conditional expression $c$ of the form $e_1 ? e_2 : e_3$ proceeds as follows:
 
 \LMHash{}
-First, $e_1$ is evaluated to an object $o_1$.  Then, $o_1$ is  subjected to boolean conversion (\ref{booleanConversion}) producing an object $r$.  If $r$ is \TRUE, then the value of $c$ is the result of evaluating the expression $e_2$. Otherwise the value of $c$ is the result of evaluating the expression $e_3$. 
+First, $e_1$ is evaluated to an object $o_1$.  Then, $o_1$ is  subjected to boolean conversion (\ref{booleanConversion}) producing an object $r$.  If $r$ is \TRUE, then the value of $c$ is the result of evaluating the expression $e_2$. Otherwise the value of $c$ is the result of evaluating the expression $e_3$.
 
 \LMHash{}
 If all of the following hold:
@@ -4650,11 +4663,11 @@ then the type of $v$ is known to be $T$ in $e_2$.
 
 \LMHash{}
  It is a static type warning if the static type of $e_1$ may not be assigned to \code{bool}.  The static type of $c$ is the least upper bound (\ref{leastUpperBounds}) of the static type of $e_2$ and the static type of $e_3$.
- 
-   
+
+
  \subsection{If-null Expressions}
  \label{ifNull}
- 
+
  \LMHash{}
  An {\em if-null expression}evaluates an expression and if the result is \NULL, evaluates another.
 
@@ -4662,10 +4675,10 @@ then the type of $v$ is known to be $T$ in $e_2$.
 {\bf ifNullExpression:}
   logicalOrExpression (`??' logicalOrExpression)*
 \end{grammar}
-  
+
 \LMHash{}
 Evaluation of an if-null expression $e$ of the form $e_1??e_2 $ is equivalent to the evaluation of the expression $((x) => x == \NULL? e_2: x)(e_1)$. The static type of $e$ is least upper bound (\ref{leastUpperBounds}) of the static type of $e_1$ and the static type of $e_2$.
-  
+
 
 \subsection{ Logical Boolean Expressions}
 \LMLabel{logicalBooleanExpressions}
@@ -4684,18 +4697,18 @@ The logical boolean expressions combine boolean objects using the boolean conjun
 %      bitwiseOrExpression (`\&\&' bitwiseOrExpression)*
     .
  \end{grammar}
- 
+
 \LMHash{}
 A {\em logical boolean expression} is either an equality expression (\ref{equality}), or an invocation of a logical boolean operator on an expression $e_1$ with argument $e_2$.
- 
+
 \LMHash{}
-Evaluation of a logical boolean expression $b$ of the form $e_1 || e_2$ causes the evaluation of $e_1$ which is then  subjected to boolean conversion, yielding an object $o_1$; if $o_1$ is \TRUE, the result of evaluating $b$ is \TRUE, otherwise $e_2$ is evaluated to an object $o_2$, which is then subjected to boolean conversion (\ref{booleanConversion}) producing an object $r$, which is the value of $b$. 
+Evaluation of a logical boolean expression $b$ of the form $e_1 || e_2$ causes the evaluation of $e_1$ which is then  subjected to boolean conversion, yielding an object $o_1$; if $o_1$ is \TRUE, the result of evaluating $b$ is \TRUE, otherwise $e_2$ is evaluated to an object $o_2$, which is then subjected to boolean conversion (\ref{booleanConversion}) producing an object $r$, which is the value of $b$.
 
 \LMHash{}
-Evaluation of a logical boolean expression $b$ of the form $e_1 \&\& e_2$ causes the evaluation of $e_1$ which is then subjected to boolean conversion, yielding an object $o_1$; if $o_1$ is not  \TRUE, the result of evaluating $b$ is \FALSE, otherwise $e_2$ is evaluated to an object $o_2$, which is then subjected to boolean conversion producing an object $r$, which is the value of $b$. 
+Evaluation of a logical boolean expression $b$ of the form $e_1 \&\& e_2$ causes the evaluation of $e_1$ which is then subjected to boolean conversion, yielding an object $o_1$; if $o_1$ is not  \TRUE, the result of evaluating $b$ is \FALSE, otherwise $e_2$ is evaluated to an object $o_2$, which is then subjected to boolean conversion producing an object $r$, which is the value of $b$.
 
 \LMHash{}
-A logical boolean expression $b$ of the form $e_1 \&\& e_2$ shows that a variable $v$ has type 
+A logical boolean expression $b$ of the form $e_1 \&\& e_2$ shows that a variable $v$ has type
 $T$ if all of the following conditions hold:
 \begin{itemize}
 \item Either $e_1$ shows that $v$ has type $T$ or $e_2$ shows that $v$ has type $T$.
@@ -4708,17 +4721,17 @@ Furthermore, if all of the following hold:
 \begin{itemize}
 \item $e_1$ shows that $v$ has type $T$.
 \item $v$ is not mutated in either $e_1$, $e_2$ or within a closure.
-\item If the variable $v$ is accessed by a closure in $e_2$ then the variable $v$ is not potentially mutated anywhere in the scope of $v$. 
+\item If the variable $v$ is accessed by a closure in $e_2$ then the variable $v$ is not potentially mutated anywhere in the scope of $v$.
 \end{itemize}
 then the type of $v$ is known to be $T$ in $e_2$.
 
 \LMHash{}
 It is a static warning if the static type of $e_1$ may not be assigned to \cd{bool} or if the static type of $e_2$ may not be assigned to \cd{bool}. The static type of a logical boolean expression is \code{bool}.
 
-     
+
  \subsection{ Equality}
  \LMLabel{equality}
- 
+
 \LMHash{}
 Equality expressions test objects for equality.
 
@@ -4731,7 +4744,7 @@ Equality expressions test objects for equality.
       `!='
     .
  \end{grammar}
- 
+
 \LMHash{}
 An {\em equality expression} is either a relational expression (\ref{relationalExpressions}), or an invocation of an equality operator on either \SUPER{} or an expression $e_1$, with argument $e_2$.
 
@@ -4755,24 +4768,24 @@ Evaluation of an equality expression $ee$ of the form \code{\SUPER{} == $e$} pro
 \end{itemize}
 
 \commentary{As a result of the above definition, user defined \code{==} methods can assume that their argument is non-null, and avoid the standard boiler-plate prelude:
- 
+
  \code{if (identical(\NULL{}, arg)) return \FALSE{};}
 
-Another implication is that there is never a need to use \code{identical()} to test against \NULL{}, nor should anyone ever worry about whether to write \NULL{} == $e$ or $e$ == \NULL{}. 
+Another implication is that there is never a need to use \code{identical()} to test against \NULL{}, nor should anyone ever worry about whether to write \NULL{} == $e$ or $e$ == \NULL{}.
 }
 
 \LMHash{}
 An equality expression of the form \code{$e_1$ != $e_2$}  is equivalent to the expression \code{!($e_1$ == $e_2$)}. An equality expression of the form \code{\SUPER{} != $e$} is equivalent to the expression \code{!(\SUPER{} == $e$)}.
 
 
- 
- %The expression $e_1$ is evaluated to an object $o_1$; then the expression $e_2$ is evaluated to an object $o_2$.  Next, if $o_1$ and $o_2$ are the same object, then $ee$ evaluates to \TRUE{}, otherwise $ee$ evaluates to \FALSE{}. 
- 
+
+ %The expression $e_1$ is evaluated to an object $o_1$; then the expression $e_2$ is evaluated to an object $o_2$.  Next, if $o_1$ and $o_2$ are the same object, then $ee$ evaluates to \TRUE{}, otherwise $ee$ evaluates to \FALSE{}.
+
 
 \LMHash{}
  The static type of an equality expression is \code{bool}.
- 
- 
+
+
 \subsection{ Relational Expressions}
 \LMLabel{relationalExpressions}
 
@@ -4791,12 +4804,12 @@ Relational expressions invoke the relational operators on objects.
       `{\escapegrammar \lt}'
     .
  \end{grammar}
- 
+
 \LMHash{}
 A {\em relational expression} is either a bitwise expression (\ref{bitwiseExpressions}), or an invocation of a relational operator on either \SUPER{} or an expression $e_1$, with argument $e_2$.
- 
+
 \LMHash{}
-A relational expression of the form  $e_1$ $op$ $e_2$ is equivalent to the method invocation \code{$e_1$.$op$($e_2$)}. A relational expression of the form  \SUPER{} $op$ $e_2$ is equivalent to the method invocation \code{\SUPER{}.$op$($e_2$)}. 
+A relational expression of the form  $e_1$ $op$ $e_2$ is equivalent to the method invocation \code{$e_1$.$op$($e_2$)}. A relational expression of the form  \SUPER{} $op$ $e_2$ is equivalent to the method invocation \code{\SUPER{}.$op$($e_2$)}.
 
 \subsection{ Bitwise Expressions}
 \LMLabel{bitwiseExpressions}
@@ -4822,10 +4835,10 @@ Bitwise expressions invoke the bitwise operators on objects.
       `$|$'
     .
  \end{grammar}
- 
+
 \LMHash{}
 A {\em bitwise expression} is either a shift expression (\ref{shift}), or an invocation of a bitwise operator on either \SUPER{} or an expression $e_1$, with argument $e_2$.
- 
+
 \LMHash{}
  A bitwise expression of the form  $e_1$ $op$ $e_2$ is equivalent to the method invocation $e_1.op(e_2)$.
 A bitwise expression of the form  \code{\SUPER{} $op$ $e_2$} is equivalent to the method invocation \code{\SUPER{}.op($e_2$)}.
@@ -4834,7 +4847,7 @@ A bitwise expression of the form  \code{\SUPER{} $op$ $e_2$} is equivalent to th
 It should be obvious that the static type rules for these expressions are defined by the equivalence above - ergo, by the type rules for method invocation and the signatures of the operators on the type $e_1$. The same holds in similar situations throughout this specification.
 }
 
- 
+
 \subsection{ Shift}
 \LMLabel{shift}
 
@@ -4847,25 +4860,25 @@ Shift expressions invoke the shift operators on objects.
     .
 
 {\bf shiftOperator:}`{\escapegrammar \lt\lt'};
-       `{\escapegrammar \gt \gt}' 
+       `{\escapegrammar \gt \gt}'
     .
  \end{grammar}
- 
+
 \LMHash{}
 A {\em shift expression} is either an additive expression (\ref{additiveExpressions}), or an invocation of a shift operator on either \SUPER{} or an expression $e_1$, with argument $e_2$.
- 
+
 \LMHash{}
- A shift expression of the form  $e_1$ $op$ $e_2$ is equivalent to the method invocation \code{$e_1$.$op$($e_2$)}. A shift expression of the form  \SUPER{} $op$ $e_2$ is equivalent to the method invocation \code{\SUPER{}.$op$($e_2$)}. 
+ A shift expression of the form  $e_1$ $op$ $e_2$ is equivalent to the method invocation \code{$e_1$.$op$($e_2$)}. A shift expression of the form  \SUPER{} $op$ $e_2$ is equivalent to the method invocation \code{\SUPER{}.$op$($e_2$)}.
 
 \commentary{
-Note that this definition implies left-to-right evaluation order among shift expressions: 
+Note that this definition implies left-to-right evaluation order among shift expressions:
 
 $e_1 << e_2 << e_3$
 
 is evaluated as  $(e_1 << e_2 ).<< (e_3)$  which is equivalent to $(e_1 << e_2) << e_3$.
 The same holds for additive and multiplicative expressions.
 }
-     
+
  \subsection{ Additive Expressions}
 \LMLabel{additiveExpressions}
 
@@ -4881,17 +4894,17 @@ Additive expressions invoke the addition operators on objects.
       `-'
     .
  \end{grammar}
- 
+
 \LMHash{}
 An {\em additive expression} is either a multiplicative expression (\ref{multiplicativeExpressions}), or an invocation of an additive operator on either \SUPER{} or an expression $e_1$, with argument $e_2$.
 
 \LMHash{}
-An additive expression of the form  $e_1$ $op$ $e_2$ is equivalent to the method invocation \code{$e_1$.$op$($e_2$)}. An additive expression of the form  \SUPER{} $op$ $e_2$ is equivalent to the method invocation \code{\SUPER{}.$op$($e_2$)}. 
+An additive expression of the form  $e_1$ $op$ $e_2$ is equivalent to the method invocation \code{$e_1$.$op$($e_2$)}. An additive expression of the form  \SUPER{} $op$ $e_2$ is equivalent to the method invocation \code{\SUPER{}.$op$($e_2$)}.
 
 \LMHash{}
 The static type of an additive expression is usually determined by the signature given in the declaration of the operator used. However, invocations of the operators \cd{+}  and \cd{-} of class \cd{int} are treated specially by the typechecker. The static type of an expression $e_1 + e_2$ where $e_1$ has static type \cd{int} is \cd{int} if the static type of $e_2$ is \cd{int}, and \cd{double} if the static type of $e_2$ is \cd{double}. The static type of an expression $e_1 - e_2$ where $e_1$ has static type \cd{int} is \cd{int} if the static type of $e_2$ is \cd{int}, and \cd{double} if the static type of $e_2$ is \cd{double}.
- 
- 
+
+
 \subsection{ Multiplicative Expressions}
 \LMLabel{multiplicativeExpressions}
 
@@ -4908,18 +4921,18 @@ Multiplicative expressions invoke the multiplication operators on objects.
       `\%';
       `\~{}/'
     .
-    
+
  \end{grammar}
-    
+
 \LMHash{}
  A {\em multiplicative expression} is either a unary expression (\ref{unaryExpressions}), or an invocation of a multiplicative operator on either \SUPER{} or an expression $e_1$, with argument $e_2$.
- 
+
 \LMHash{}
- A multiplicative expression of the form  $e_1$ $op$ $e_2$ is equivalent to the method invocation \code{$e_1$.$op$($e_2$)}. A multiplicative expression of the form  \SUPER{} $op$ $e_2$ is equivalent to the method invocation \code{\SUPER{}.$op$($e_2$)}.   
- 
+ A multiplicative expression of the form  $e_1$ $op$ $e_2$ is equivalent to the method invocation \code{$e_1$.$op$($e_2$)}. A multiplicative expression of the form  \SUPER{} $op$ $e_2$ is equivalent to the method invocation \code{\SUPER{}.$op$($e_2$)}.
+
 \LMHash{}
 The static type of an multiplicative expression is usually determined by the signature given in the declaration of the operator used. However, invocations of the operators \cd{*}, \cd{\%}  and \cd{\~{}/} of class \cd{int} are treated specially by the typechecker. The static type of an expression $e_1 * e_2$ where $e_1$ has static type \cd{int} is \cd{int} if the static type of $e_2$ is \cd{int}, and \cd{double} if the static type of $e_2$ is \cd{double}. The static type of an expression $e_1 \% e_2$ where $e_1$ has static type \cd{int} is \cd{int} if the static type of $e_2$ is \cd{int}, and \cd{double} if the static type of $e_2$ is \cd{double}.  The static type of an expression \cd{$e_1$ \~{}/ $e_2$} where $e_1$ has static type \cd{int} is \cd{int} if the static type of $e_2$ is \cd{int}.
- 
+
 \subsection{ Unary Expressions}
 \LMLabel{unaryExpressions}
 
@@ -4933,33 +4946,33 @@ Unary expressions invoke unary operators on objects.
       (minusOperator $|$ tildeOperator) \SUPER{};
       incrementOperator assignableExpression
     .
- 
+
  {\bf prefixOperator:}minusOperator;
       negationOperator;
       tildeOperator
     .
-       
-       
+
+
   {\bf minusOperator:}`-';  .
 
 
     {\bf negationOperator:}`!' ;
       .
-      
+
     {\bf tildeOperator:}  `\~{}'
     .
-    
-    
+
+
 \end{grammar}
 
 \LMHash{}
 A {\em unary expression} is either a postfix expression  (\ref{postfixExpressions}), an await expression (\ref{awaitExpressions}) or an invocation of a prefix operator on an expression or an invocation of a unary operator on either \SUPER{} or an expression $e$.
 
 \LMHash{}
-The expression $!e$ is equivalent to the expression $e?$ $ \FALSE{} :\TRUE{}$. 
+The expression $!e$ is equivalent to the expression $e?$ $ \FALSE{} :\TRUE{}$.
 
 \LMHash{}
-Evaluation of an expression of the form \code{++$e$} is equivalent to \code{$e$ += 1}.  Evaluation of an expression of the form \code{-{}-$e$} is equivalent to \code{$e$ -= 1}. 
+Evaluation of an expression of the form \code{++$e$} is equivalent to \code{$e$ += 1}.  Evaluation of an expression of the form \code{-{}-$e$} is equivalent to \code{$e$ -= 1}.
 
 %The expression $-e$ is equivalent to the method invocation \code{$e$.-()}.  The expression \code{-\SUPER{}} is equivalent  to the method invocation \code{\SUPER{}.-()}.
 
@@ -4970,7 +4983,7 @@ An expression of the form \code{$op$ $e$} is equivalent to the method invocation
 \LMLabel{awaitExpressions}
 
 \LMHash{}
-An {\em await expression} allows code to yield control until an asynchronous operation (\ref{functions}) completes. 
+An {\em await expression} allows code to yield control until an asynchronous operation (\ref{functions}) completes.
 
  \begin{grammar}
 {\bf awaitExpression:}
@@ -4982,7 +4995,7 @@ Evaluation of an await expression $a$ of the form \AWAIT{} $e$ proceeds as follo
 First, the expression $e$ is evaluated. Next:
 
 \LMHash{}
-If $e$ raises an exception $x$, then an instance $f$ of class \code{Future} is allocated and later completed with $x$. Otherwise, if $e$ evaluates to an object $o$ that is not an instance of \code{Future}, then let $f$ be the result of calling \code{Future.value()} with $o$ as its argument; otherwise let $f$ be the result of evaluating $e$. 
+If $e$ raises an exception $x$, then an instance $f$ of class \code{Future} is allocated and later completed with $x$. Otherwise, if $e$ evaluates to an object $o$ that is not an instance of \code{Future}, then let $f$ be the result of calling \code{Future.value()} with $o$ as its argument; otherwise let $f$ be the result of evaluating $e$.
 
 \LMHash{}
 Next,  execution of the function $m$ immediately enclosing $a$ is suspended until after $f$ completes. The stream associated with the innermost enclosing asynchronous for loop (\ref{asynchronousFor-in}), if any, is paused. At some time after $f$ is completed, control returns to the current invocation. The stream associated with the innermost enclosing asynchronous for loop  (\ref{asynchronousFor-in}), if any, is resumed. If $f$ has completed with an exception $x$, $a$ raises $x$. If $f$ completes with a value $v$, $a$ evaluates to $v$.
@@ -5005,7 +5018,7 @@ It is not a static warning if the type of $e$ is not a subtype of \code{Future}.
 The static type of $a$ is $flatten(T)$ (the $flatten$ function is defined in section \ref{functionExpressions}) where $T$ is the static type of $e$.
 
 
-     
+
 \subsection{ Postfix Expressions}
 \LMLabel{postfixExpressions}
 
@@ -5028,9 +5041,9 @@ Postfix expressions invoke the postfix operators on objects.
 {\bf incrementOperator:}`++';
       `-{}-'
     .
-        
+
  \end{grammar}
- 
+
 \LMHash{}
  A {\em postfix expression} is either a primary expression, a function, method or getter invocation, or an invocation of a postfix operator on an expression $e$.
 
@@ -5041,11 +5054,11 @@ Execution of a postfix expression of the form \code{$v$++}, where $v$ is an iden
 The static type of such an expression is the static type of $v$.
 
 
-\rationale{The above ensures that if $v$ is a field, the getter gets called exactly once. Likewise in the cases below. 
+\rationale{The above ensures that if $v$ is a field, the getter gets called exactly once. Likewise in the cases below.
 }
 
 \LMHash{}
-Execution of a postfix expression of the form \code{$C.v$ ++} is equivalent to executing 
+Execution of a postfix expression of the form \code{$C.v$ ++} is equivalent to executing
 
 \code{()\{\VAR{} r = $C.v$; $C.v$ = r + 1; \RETURN{} r\}()}.
 
@@ -5054,7 +5067,7 @@ The static type of such an expression is the static type of $C.v$.
 
 
 \LMHash{}
-Execution of a postfix expression of the form \code{$e_1.v$++} is equivalent to executing 
+Execution of a postfix expression of the form \code{$e_1.v$++} is equivalent to executing
 
 \code{(x)\{\VAR{} r = x.v; x.v = r + 1; \RETURN{} r\}($e_1$)}.
 
@@ -5063,7 +5076,7 @@ The static type of such an expression is the static type of $e_1.v$.
 
 
 \LMHash{}
-Execution of a postfix expression of the form \code{$e_1[e_2]$++},  is equivalent to executing 
+Execution of a postfix expression of the form \code{$e_1[e_2]$++},  is equivalent to executing
 
 \code{(a, i)\{\VAR{} r = a[i]; a[i] = r + 1; \RETURN{} r\}($e_1$, $e_2$)}.
 
@@ -5072,7 +5085,7 @@ The static type of such an expression is the static type of $e_1[e_2]$.
 
 
 \LMHash{}
-Execution of a postfix expression of the form \code{$v$-{}-}, where $v$ is an identifier, is equivalent to executing 
+Execution of a postfix expression of the form \code{$v$-{}-}, where $v$ is an identifier, is equivalent to executing
 
 \code{()\{\VAR{} r = $v$; $v$ = r - 1; \RETURN{} r\}()}.
 
@@ -5081,7 +5094,7 @@ The static type of such an expression is the static type of $v$.
 
 
 \LMHash{}
-Execution of a postfix expression of the form \code{$C.v$-{}-} is equivalent to executing 
+Execution of a postfix expression of the form \code{$C.v$-{}-} is equivalent to executing
 
 \code{()\{\VAR{} r = $C.v$; $C.v$ = r - 1; \RETURN{} r\}()}.
 
@@ -5090,7 +5103,7 @@ The static type of such an expression is the static type of $C.v$.
 
 
 \LMHash{}
-Execution of a postfix expression of the form \code{$e_1.v$-{}-} is equivalent to executing 
+Execution of a postfix expression of the form \code{$e_1.v$-{}-} is equivalent to executing
 
 \code{(x)\{\VAR{} r = x.v; x.v = r - 1; \RETURN{} r\}($e_1$)}.
 
@@ -5099,7 +5112,7 @@ The static type of such an expression is the static type of $e_1.v$.
 
 
 \LMHash{}
-Execution of a postfix expression of the form \code{$e_1[e_2]$-{}-},  is equivalent to executing 
+Execution of a postfix expression of the form \code{$e_1[e_2]$-{}-},  is equivalent to executing
 
 \code{(a, i)\{\VAR{} r = a[i]; a[i] = r - 1; \RETURN{} r\}($e_1$, $e_2$)}.
 
@@ -5107,7 +5120,7 @@ Execution of a postfix expression of the form \code{$e_1[e_2]$-{}-},  is equival
 The static type of such an expression is the static type of $e_1[e_2]$.
 
 \LMHash{}
-Execution of a postfix expression of the form \code{$e_1?.v$++} is equivalent to executing 
+Execution of a postfix expression of the form \code{$e_1?.v$++} is equivalent to executing
 
 \code{((x) =$>$ x == \NULL? \NULL : x.v++)($e_1$)}
 unless $e_1$ is a type literal, in which case it is equivalent to \code{$e_1.v$++}
@@ -5117,7 +5130,7 @@ unless $e_1$ is a type literal, in which case it is equivalent to \code{$e_1.v$+
 The static type of such an expression is the static type of $e_1.v$.
 
 \LMHash{}
-Execution of a postfix expression of the form \code{$e_1?.v$-{}-} is equivalent to executing 
+Execution of a postfix expression of the form \code{$e_1?.v$-{}-} is equivalent to executing
 
 \code{((x) =$>$ x == \NULL? \NULL : x.v-{}-)($e_1$)}
 unless $e_1$ is a type literal, in which case it is equivalent to \code{$e_1.v$-{}-}
@@ -5146,7 +5159,7 @@ Of course, if assignable expressions always appeared {\em as} the left hand side
       \SUPER{} unconditionalAssignableSelector;
       identifier
     .
-    
+
 {\bf unconditionalAssignableSelector:}`[' expression `]'; % again, could be top level
          `{\escapegrammar .}' identifier
     .
@@ -5162,7 +5175,7 @@ Of course, if assignable expressions always appeared {\em as} the left hand side
 \LMHash{}
 An {\em assignable expression} is either:
 \begin{itemize}
- \item An identifier. 
+ \item An identifier.
 \item An invocation (possibly conditional) of a getter (\ref{getters}) or list access operator on an expression $e$.
 \item An invocation of a getter or list access operator on  \SUPER{}.
 \end{itemize}
@@ -5195,8 +5208,8 @@ An {\em identifier expression} consists of a single identifier; it provides acce
 {\bf identifier:}
      IDENTIFIER
      .
-     
-         
+
+
  {\bf IDENTIFIER\_NO\_DOLLAR:}
       IDENTIFIER\_START\_NO\_DOLLAR IDENTIFIER\_PART\_NO\_DOLLAR*
     .
@@ -5243,8 +5256,8 @@ An {\em identifier expression} consists of a single identifier; it provides acce
 
 
 {\bf qualified:}
-      identifier (`{\escapegrammar .}' identifier)?  
-      . 
+      identifier (`{\escapegrammar .}' identifier)?
+      .
 \end{grammar}
 
 \LMHash{}
@@ -5266,27 +5279,27 @@ Evaluation of an identifier expression $e$ of the form $id$ proceeds as follows:
 
 
 \LMHash{}
-Let $d$ be the innermost declaration in the enclosing lexical scope whose name is $id$ or $id=$.  If no such declaration exists in the lexical scope, let $d$ be the declaration of the inherited member named $id$ if it exists. 
+Let $d$ be the innermost declaration in the enclosing lexical scope whose name is $id$ or $id=$.  If no such declaration exists in the lexical scope, let $d$ be the declaration of the inherited member named $id$ if it exists.
 %If no such member exists, let $d$ be the declaration of the static member name $id$ declared in a superclass of the current class, if it exists.
 
 \begin{itemize}
-\item if $d$ is a prefix $p$, a compile-time error occurs unless the token immediately following $d$ is \code{'.'}.
+\item if $d$ is a prefix $p$, a compile-time error occurs unless the token immediately following $d$ is \code{'.'} or \code{'\#'}.
 \item If $d$ is a class or type alias $T$, the value of $e$ is an instance of  class \code{Type} (or a subclass thereof) reifying $T$.
 \item If $d$ is a type parameter $T$, then the value of $e$ is the value of the actual type argument corresponding to $T$ that was  passed to the generative constructor that created the current binding of \THIS{}. If, however, $e$ occurs inside a static member, a compile-time error occurs.
 
 %\commentary{ We are assured that \THIS{} is well defined, because if we were in a static member the reference to $T$ is a compile-time error (\ref{generics}.)}
 %\item If $d$ is a library variable then:
 %  \begin{itemize}
-%  \item If $d$ is of one of the forms \code{\VAR{} $v$ = $e_i$;} , \code{$T$ $v$ = $e_i$;} , \code{\FINAL{} $v$ = $e_i$;}  or \code{\FINAL{} $T$ $v$ = $e_i$;} and no value has yet been stored into $v$ then the initializer expression $e_i$ is evaluated. If, during the evaluation of $e_i$, the getter for $v$ is referenced, a \code{CyclicInitializationError} is thrown. If the evaluation succeeded yielding an object $o$, let $r = o$, otherwise let $r = \NULL{}$. In any case, $r$ is stored into $v$. The value of $e$ is $r$. 
+%  \item If $d$ is of one of the forms \code{\VAR{} $v$ = $e_i$;} , \code{$T$ $v$ = $e_i$;} , \code{\FINAL{} $v$ = $e_i$;}  or \code{\FINAL{} $T$ $v$ = $e_i$;} and no value has yet been stored into $v$ then the initializer expression $e_i$ is evaluated. If, during the evaluation of $e_i$, the getter for $v$ is referenced, a \code{CyclicInitializationError} is thrown. If the evaluation succeeded yielding an object $o$, let $r = o$, otherwise let $r = \NULL{}$. In any case, $r$ is stored into $v$. The value of $e$ is $r$.
  \item  If $d$ is a constant variable of one of the forms  \code{\CONST{} $v$ = $e$;} or \code{\CONST{} $T$ $v$ = $e$;} then the value $id$ is the value of the compile-time constant $e$.
 %  Otherwise
-%  \item $e$ evaluates to the current binding of $id$.  
+%  \item $e$ evaluates to the current binding of $id$.
 %  \end{itemize}
-\item If $d$ is a local variable or formal parameter then $e$ evaluates to the current binding of $id$. 
+\item If $d$ is a local variable or formal parameter then $e$ evaluates to the current binding of $id$.
 %\item If $d$ is a library variable, local variable, or formal parameter, then $e$ evaluates to the current binding of $id$. \commentary{This case also applies if d is a library or local function declaration, as these are equivalent to function-valued variable declarations.}
 \item If $d$ is a static method, top-level function or local function then $e$ evaluates to the function defined by $d$.
-\item If $d$ is the declaration of a static variable, static getter or static setter declared in class $C$, then $e$ is equivalent to the property extraction (\ref{propertyExtraction}) $C.id$. 
-\item If $d$ is the declaration of a library variable, top-level getter or top-level setter, then $e$ is equivalent to the top level getter invocation (\ref{topLevelGetterInvocation}) $id$. 
+\item If $d$ is the declaration of a static variable, static getter or static setter declared in class $C$, then $e$ is equivalent to the property extraction (\ref{propertyExtraction}) $C.id$.
+\item If $d$ is the declaration of a library variable, top-level getter or top-level setter, then $e$ is equivalent to the top level getter invocation (\ref{topLevelGetterInvocation}) $id$.
 \item Otherwise, if $e$ occurs inside a top level or static function (be it function, method, getter,  or setter) or variable initializer, evaluation of $e$ causes a \code{NoSuchMethod} to be thrown.
 \item Otherwise, $e$ is equivalent to the property extraction (\ref{propertyExtraction}) \THIS{}.$id$.
 % This implies that referring to an undefined static getter by simple name is an error, whereas doing so by qualified name is only a warning. Same with assignments.  Revise?
@@ -5297,20 +5310,20 @@ The static type of $e$ is determined as follows:
 
 \begin{itemize}
 \item If $d$ is a class, type alias or type parameter the static type of $e$ is \code{Type}.
-\item If $d$ is a local variable or formal parameter the static type of $e$ is the type of the variable $id$, unless $id$ is known to have some type $T$, in which case the static type of $e$ is $T$, provided that $T$ is more specific than any other type $S$ such that $v$ is known to have type $S$. 
+\item If $d$ is a local variable or formal parameter the static type of $e$ is the type of the variable $id$, unless $id$ is known to have some type $T$, in which case the static type of $e$ is $T$, provided that $T$ is more specific than any other type $S$ such that $v$ is known to have type $S$.
 \item If $d$ is a static method, top-level function or local function the static type of $e$ is the function type defined by $d$.
 \item If $d$ is the declaration of a static variable, static getter or static setter declared in class $C$, the static type of $e$ is the static type of the getter invocation (\ref{propertyExtraction}) $C.id$.
-\item If $d$ is the declaration of a library variable, top-level getter or top-level setter, the static type of $e$  is the static type of the top level getter invocation $id$. 
+\item If $d$ is the declaration of a library variable, top-level getter or top-level setter, the static type of $e$  is the static type of the top level getter invocation $id$.
 \item Otherwise, if $e$ occurs inside a top level or static function (be it function, method, getter,  or setter) or variable initializer, the static type of $e$ is \DYNAMIC{}.
 \item Otherwise, the static type of $e$ is the type of the property extraction (\ref{propertyExtraction}) \THIS{}.$id$.
 \end{itemize}
 
  \commentary{Note that if one declares a setter, we bind to the corresponding getter even if it does not exist.}
- 
+
  \rationale{
  This prevents situations where one uses uncorrelated setters and getters. The intent is to prevent errors when a  getter in a surrounding scope is used accidentally.
  }
- 
+
 \LMHash{}
 It is a static warning if an identifier expression $id$ occurs inside a top level or static function (be it function, method, getter, or setter) or variable initializer and there is no declaration $d$ with name $id$ in the lexical scope enclosing the expression.
 
@@ -5324,20 +5337,20 @@ The {\em is-expression} tests if an object is a member of a type.
  {\bf typeTest:}
  isOperator type
  .
- 
- 
+
+
 {\bf isOperator:}
 \IS{} `!'?
     .
  \end{grammar}
- 
+
 \LMHash{}
  Evaluation of the is-expression \code{$e$ \IS{} $T$} proceeds as follows:
 
 \LMHash{}
 The expression $e$ is evaluated to a value $v$. Then, if $T$ is a malformed or deferred type (\ref{staticTypes}), a dynamic error occurs. Otherwise, if the interface of the class of $v$ is a subtype of $T$, the is-expression evaluates to \TRUE. Otherwise it evaluates to \FALSE.
 
-\commentary{It follows that \code{$e$ \IS{} Object} is always true. This makes sense in a language where everything is an object. 
+\commentary{It follows that \code{$e$ \IS{} Object} is always true. This makes sense in a language where everything is an object.
 
 Also note that \code{\NULL{} \IS{} $T$} is false unless $T = \code{Object}$, $T = \code{\DYNAMIC{}}$ or $T = \code{Null}$.  The former two are useless, as is anything of the form \code{$e$ \IS{} Object} or \code{$e$ \IS{} \DYNAMIC{}}.  Users should test for a null value directly rather than via type tests.
 }
@@ -5362,7 +5375,7 @@ We do not want to refine the type of a variable of type \DYNAMIC{}, as this coul
 }
 
 \LMHash{}
-The static type of an is-expression is \code{bool}. 
+The static type of an is-expression is \code{bool}.
 
 
 \subsection{ Type Cast}
@@ -5375,22 +5388,22 @@ The {\em cast expression} ensures that an object is a member of a type.
  {\bf typeCast:}
  asOperator type
  .
- 
- 
+
+
 {\bf asOperator:}
 \AS{}
     .
  \end{grammar}
- 
+
 \LMHash{}
  Evaluation of the cast expression \code{$e$ \AS{} $T$} proceeds as follows:
 
 \LMHash{}
-The expression $e$ is evaluated to a value $v$. Then, if $T$ is a malformed or deferred type (\ref{staticTypes}), a dynamic error occurs. Otherwise, if the interface of the class of $v$ is a subtype of $T$, the cast expression evaluates to $v$. Otherwise, if $v$ is \NULL{}, the cast expression evaluates to $v$. 
+The expression $e$ is evaluated to a value $v$. Then, if $T$ is a malformed or deferred type (\ref{staticTypes}), a dynamic error occurs. Otherwise, if the interface of the class of $v$ is a subtype of $T$, the cast expression evaluates to $v$. Otherwise, if $v$ is \NULL{}, the cast expression evaluates to $v$.
 In all other cases,  a \code{CastError} is thrown.
- 
+
 \LMHash{}
-The static type of a cast expression  \code{$e$ \AS{} $T$}  is $T$. 
+The static type of a cast expression  \code{$e$ \AS{} $T$}  is $T$.
 
 
 \section{Statements}
@@ -5406,7 +5419,7 @@ The static type of a cast expression  \code{$e$ \AS{} $T$}  is $T$.
       label* nonLabelledStatement
     .
 
-{\bf nonLabelledStatement:}block; 
+{\bf nonLabelledStatement:}block;
       localVariableDeclaration;
       forStatement;
       whileStatement;
@@ -5425,10 +5438,10 @@ The static type of a cast expression  \code{$e$ \AS{} $T$}  is $T$.
       localFunctionDeclaration
     .
  \end{grammar}
- 
+
  \subsection{Blocks}
  \LMLabel{blocks}
- 
+
 \LMHash{}
  A {\em block statement} supports sequencing of code.
 
@@ -5445,9 +5458,9 @@ A block statement introduces a new scope, which is nested in the lexically enclo
 
  \subsection{Expression Statements}
  \LMLabel{expressionStatements}
- 
+
 \LMHash{}
-An {\em expression statement} consists of an expression other than a non-constant map literal (\ref{maps}) that has no explicit type arguments. 
+An {\em expression statement} consists of an expression other than a non-constant map literal (\ref{maps}) that has no explicit type arguments.
 
 \rationale{
 The restriction on maps  is designed to resolve an ambiguity in the grammar, when a statement begins with \{.
@@ -5458,9 +5471,9 @@ The restriction on maps  is designed to resolve an ambiguity in the grammar, whe
   expression? `{\escapegrammar ;}'
   .
  \end{grammar}
- 
+
 \LMHash{}
-Execution of an expression statement \code{$e$;} proceeds by evaluating $e$. 
+Execution of an expression statement \code{$e$;} proceeds by evaluating $e$.
 
 \LMHash{}
 It is a compile-time error if a non-constant map literal that has no explicit type arguments appears in a place where a statement is expected.
@@ -5477,15 +5490,15 @@ A {\em variable declaration statement }declares a new local variable.
     initializedVariableDeclaration {\escapegrammar';'}
   .
  \end{grammar}
- 
+
 \LMHash{}
  Executing a variable declaration statement of one of the forms  \VAR{} $v = e;$, $T$ $v = e; $, \CONST{}  $v = e;$, \CONST{} $T$ $v = e;$, \FINAL{}  $v = e;$ or \FINAL{} $T$ $v = e;$ proceeds as follows:
- 
+
 \LMHash{}
  The expression $e$ is evaluated to an object $o$. Then, the variable $v$ is set to $o$.
- 
+
 \LMHash{}
- A variable declaration statement of the form \VAR{} $v;$ is equivalent to \VAR{} $v = \NULL{};$. A variable declaration statement of the form $T$ $v;$ is equivalent to $T$ $v = \NULL{};$. 
+ A variable declaration statement of the form \VAR{} $v;$ is equivalent to \VAR{} $v = \NULL{};$. A variable declaration statement of the form $T$ $v;$ is equivalent to $T$ $v = \NULL{};$.
 
 \commentary{
 This holds regardless of the type $T$. For example, \code{int i;} does not cause \code{i} to be initialized to zero. Instead, \code{i} is initialized to \NULL{}, just as if we had written \VAR{} \code{i;} or \code{Object i;} or \code{Collection$<$String$>$ i;}.
@@ -5495,13 +5508,13 @@ This holds regardless of the type $T$. For example, \code{int i;} does not cause
 To do otherwise would undermine the optionally typed nature of Dart, causing type annotations to modify program behavior.
 }
 
-%A variable declaration statement of one of the forms $T$ $v;$, $T$ $v = e;$, \CONST{} $T$ $v = e;$,  or \FINAL{} $T$ $v = e;$ causes a new getter named $v$ with static return type $T$ to be added to the innermost enclosing scope at the point following the variable declaration statement. The result of executing this getter is the value stored in $v$. 
+%A variable declaration statement of one of the forms $T$ $v;$, $T$ $v = e;$, \CONST{} $T$ $v = e;$,  or \FINAL{} $T$ $v = e;$ causes a new getter named $v$ with static return type $T$ to be added to the innermost enclosing scope at the point following the variable declaration statement. The result of executing this getter is the value stored in $v$.
 
-%A variable declaration statement \VAR{} $v;$, \VAR{} $v = e;$, \CONST{}  $v = e;$ or  \FINAL{}  $v = e;$ causes a new getter named $v$ with static return type  \DYNAMIC{} to be added to the innermost enclosing scope at the point following the variable declaration statement. The result of executing this getter  is the value stored in $v$. 
+%A variable declaration statement \VAR{} $v;$, \VAR{} $v = e;$, \CONST{}  $v = e;$ or  \FINAL{}  $v = e;$ causes a new getter named $v$ with static return type  \DYNAMIC{} to be added to the innermost enclosing scope at the point following the variable declaration statement. The result of executing this getter  is the value stored in $v$.
 
-%A variable declaration statement of one of the forms $T$ $v;$, or $T$ $v = e;$ causes a new setter named $v=$ with argument type $T$ to be added to the innermost enclosing scope at the point following the variable declaration statement. The effect of executing this setter  is to store its argument in $v$. 
+%A variable declaration statement of one of the forms $T$ $v;$, or $T$ $v = e;$ causes a new setter named $v=$ with argument type $T$ to be added to the innermost enclosing scope at the point following the variable declaration statement. The effect of executing this setter  is to store its argument in $v$.
 
-%A variable declaration statement \VAR{} $v;$, \VAR{} $v = e;$, \CONST{}  $v = e;$ or  \FINAL{}  $v = e;$ causes a new setter named $v=$ with  argument type  \DYNAMIC{} to be added to the innermost enclosing scope at the point following the variable declaration statement. The effect of executing this setter  is to store its argument in $v$. 
+%A variable declaration statement \VAR{} $v;$, \VAR{} $v = e;$, \CONST{}  $v = e;$ or  \FINAL{}  $v = e;$ causes a new setter named $v=$ with  argument type  \DYNAMIC{} to be added to the innermost enclosing scope at the point following the variable declaration statement. The effect of executing this setter  is to store its argument in $v$.
 
 %\rationale{
  %The use of getters and setters here is a device to help make the specification more uniform. Introducing getters and setters for local variables has no performance consequences, since they can never be overridden, and so can always be optimized away.  It is not possible to declare a local getter or setter explicitly, since there is little reason to ever do so.
@@ -5512,16 +5525,16 @@ To do otherwise would undermine the optionally typed nature of Dart, causing typ
 \LMLabel{localFunctionDeclaration}
 
 \LMHash{}
-A function declaration statement declares a new local function (\ref{functionDeclarations}). 
+A function declaration statement declares a new local function (\ref{functionDeclarations}).
 
  \begin{grammar}
 {\bf localFunctionDeclaration:}
     functionSignature functionBody
   .
  \end{grammar}
- 
+
 \LMHash{}
-A function declaration statement of one of the forms $id$ $signature$ $\{ statements \}$ or $T$ $id$ $signature$ $\{ statements \}$ causes a new function named $id$ to be added to the innermost enclosing scope. It is a compile-time error to reference a local function before its declaration. 
+A function declaration statement of one of the forms $id$ $signature$ $\{ statements \}$ or $T$ $id$ $signature$ $\{ statements \}$ causes a new function named $id$ to be added to the innermost enclosing scope. It is a compile-time error to reference a local function before its declaration.
 
 
 \commentary{ This implies that local functions can be directly recursive, but not mutually recursive. Consider these examples:
@@ -5535,12 +5548,12 @@ top() \{ // another top level function
   g1(x) $=>$ h(x, 1); // error: h is not declared yet
   h(x, n) $=>$ x $>$ 1? h(x-1, n*x): n; // again, recursion is fine
   g2(x) $=>$ h(x, 1); // legal
-  
+
   p1(x) $=>$ q(x,x); // illegal
   q1(a, b)$ =>$ a $>$ 0 ? p1(a-1): b; // fine
 
   q2(a, b) $=>$ a $>$ 0 ? p2(a-1): b; // illegal
-  p1(x) $=>$ q2(x,x); // fine  
+  p1(x) $=>$ q2(x,x); // fine
 \}
 \end{dartCode}
 
@@ -5550,9 +5563,9 @@ There is no way to write a pair of mutually recursive local functions, because o
 
 \begin{dartCode}
 top2() \{ // a top level function
- \VAR{} p, q;  
-  p = (x) $=>$ q(x,x); 
-  q = (a, b) $=>$ a $>$ 0 ? p(a-1): b; 
+ \VAR{} p, q;
+  p = (x) $=>$ q(x,x);
+  q = (a, b) $=>$ a $>$ 0 ? p(a-1): b;
 
 \}
 \end{dartCode}
@@ -5574,24 +5587,24 @@ The {\em if statement} allows for conditional execution of statements.
       \IF{} `(' expression `)' statement ( \ELSE{} statement)? % we could allow top level expression
     .
  \end{grammar}
- 
+
 Execution of an if statement of the form  \code {\IF{} (}$b$\code{)}$s_1$ \code{\ELSE{} } $s_2$ proceeds as follows:
- 
+
 \LMHash{}
  First, the expression $b$ is evaluated to an object $o$. Then, $o$ is  subjected to boolean conversion (\ref{booleanConversion}), producing an object $r$. If $r$ is \TRUE{}, then the statement $\{s_1\}$ is executed, otherwise statement $\{s_2\}$ is executed.
 
- 
+
  \commentary {
  Put another way, \code {\IF{} (}$b$\code{)}$s_1$ \code{\ELSE{} } $s_2$ is equivalent to
  \code {\IF{} (}$b$\code{)}$\{s_1\}$ \code{\ELSE{} } $\{s_2\}$
  }
- 
+
  \rationale {
  The reason for this equivalence is to catch errors such as
  }
  \begin{dartCode}
 \VOID{} main() \{
-  \IF{} (somePredicate) 
+  \IF{} (somePredicate)
     \VAR{} v = 2;
   print(v);
 \}
@@ -5600,26 +5613,26 @@ Execution of an if statement of the form  \code {\IF{} (}$b$\code{)}$s_1$ \code{
 \rationale {
 Under reasonable scope rules  such code is problematic. If we assume that \code{v} is declared in the scope of the method \code{main()}, then when \code{somePredicate} is false, \code{v} will be uninitialized when accessed.  The cleanest approach would be to require a block following the test, rather than an arbitrary statement. However, this goes against long standing custom, undermining Dart's goal of familiarity.  Instead, we choose to insert a block, introducing a scope,  around the statement following the predicate (and similarly for \ELSE{} and loops). This will cause both a warning and a runtime error in the case above.  Of course, if there is a declaration of \code{v} in the surrounding scope, programmers might still be surprised. We expect tools to highlight cases of shadowing to help avoid such situations.
  }
- 
+
 \LMHash{}
-  It is a static type warning if the type of the expression $b$ may not be assigned to \code{bool}.  
-  
+  It is a static type warning if the type of the expression $b$ may not be assigned to \code{bool}.
+
 \LMHash{}
 If:
 \begin{itemize}
 \item  $b$ shows that a variable $v$ has type $T$.
 \item  $v$ is not potentially mutated in $s_1$ or within a closure.
-\item If the variable $v$ is accessed by a closure in $s_1$ then the variable $v$ is not potentially mutated anywhere in the scope of $v$. 
+\item If the variable $v$ is accessed by a closure in $s_1$ then the variable $v$ is not potentially mutated anywhere in the scope of $v$.
 \end{itemize}
-then the type of $v$ is known to be $T$ in $s_1$.  
+then the type of $v$ is known to be $T$ in $s_1$.
 
 \LMHash{}
- An if statement of the form  \code {\IF{} (}$b$\code{)}$s_1$ is equivalent to the if statement  
- 
+ An if statement of the form  \code {\IF{} (}$b$\code{)}$s_1$ is equivalent to the if statement
+
  \code {\IF{} (}$b$\code{)}$s_1$ \code{\ELSE{} \{\}}.
-     
 
-    
+
+
 \subsection{For}
 \LMLabel{for}
 
@@ -5640,7 +5653,7 @@ The {\em for statement} supports iteration.
       expression? `{\escapegrammar ;}'
     .
  \end{grammar}
- 
+
 \LMHash{}
  The for statement has three forms - the traditional for loop and two forms of the for-in statement - synchronous and asynchronous.
 
@@ -5661,7 +5674,7 @@ First the variable declaration statement \VAR{} $v = e_0$ is executed. Then:
 \label{beginFor}
 If this is the first iteration of the for loop, let $v^\prime$ be $v$. Otherwise,  let $v^\prime$ be the variable $v^{\prime\prime}$ created in the previous execution of step \ref{allocateFreshVar}.
 \item
-The expression $[v^\prime/v]c$ is evaluated and subjected to boolean conversion (\ref{booleans}). If the result is \FALSE{}, the for loop completes. Otherwise, execution continues at step    
+The expression $[v^\prime/v]c$ is evaluated and subjected to boolean conversion (\ref{booleans}). If the result is \FALSE{}, the for loop completes. Otherwise, execution continues at step
 \ref{beginIteration}.
 \item
 \label{beginIteration}
@@ -5699,19 +5712,19 @@ It is a static warning if the static type of $c$ may not be assigned to \cd{bool
 \LMLabel{for-in}
 
 \LMHash{}
-A for statement of the form \code{ \FOR{} ($finalConstVarOrType?$ id \IN{} $e$) $s$} is equivalent to the following code: 
+A for statement of the form \code{ \FOR{} ($finalConstVarOrType?$ id \IN{} $e$) $s$} is equivalent to the following code:
 
 \begin{dartCode}
 var n0 = $e$.iterator;
 \WHILE{} (n0.moveNext()) \{
    $finalConstVarOrType?$ id = n0.current;
-   $s$ 
+   $s$
 \}
 \end{dartCode}
 where \code{n0} is an identifier that does not occur anywhere in the program, except that for purposes of static typechecking, it is checked under the assumption that $n0$ is declared to be of type $T$, where $T$ is the static type of $e.iterator$.
 
- 
- 
+
+
 \subsubsection{Asynchronous For-in}
 \LMLabel{asynchronousFor-in}
 
@@ -5739,7 +5752,7 @@ It is a compile-time error if an asynchronous for-in statement appears inside a
 
 \rationale{An asynchronous loop would make no sense within a synchronous function, for the same reasons that an await expression makes no sense in a synchronous function.}
 
- 
+
 \subsection{While}
 \LMLabel{while}
 
@@ -5751,16 +5764,16 @@ The while statement supports conditional iteration, where the condition is evalu
       \WHILE{} `(' expression `)' statement  % could do top level here, and in for
 .
  \end{grammar}
- 
+
 \LMHash{}
- Execution of a while statement of the form \code{\WHILE{} ($e$) $s$;} proceeds as follows: 
+ Execution of a while statement of the form \code{\WHILE{} ($e$) $s$;} proceeds as follows:
 
 \LMHash{}
 The expression $e$ is evaluated to an object $o$. Then, $o$ is  subjected to boolean conversion (\ref{booleanConversion}), producing an object $r$.  If $r$ is \TRUE{}, then the statement $\{s\}$ is executed and then the while statement is re-executed recursively. If $r$ is \FALSE{}, execution of the while statement is complete.
 
 \LMHash{}
 It is a static type warning if the static type of $e$ may not be assigned to \code{bool}.
-    
+
 
 \subsection{Do}
 \LMLabel{do}
@@ -5774,15 +5787,15 @@ The do statement supports conditional iteration, where the condition is evaluate
       .
  \end{grammar}
 
-    
+
 \LMHash{}
-Execution of a do statement of the form \code{\DO{} $s$ \WHILE{} ($e$);} proceeds as follows: 
+Execution of a do statement of the form \code{\DO{} $s$ \WHILE{} ($e$);} proceeds as follows:
 
 \LMHash{}
-The statement $\{s\}$ is executed. Then, the expression $e$ is evaluated to an object $o$. Then, $o$ is  subjected to boolean conversion (\ref{booleanConversion}), producing an object $r$. If $r$ is \FALSE{}, execution of the do statement is complete. If $r$ is \TRUE{}, then the do statement is re-executed recursively. 
+The statement $\{s\}$ is executed. Then, the expression $e$ is evaluated to an object $o$. Then, $o$ is  subjected to boolean conversion (\ref{booleanConversion}), producing an object $r$. If $r$ is \FALSE{}, execution of the do statement is complete. If $r$ is \TRUE{}, then the do statement is re-executed recursively.
 
 \LMHash{}
-It is a static type warning if the static type of $e$ may not be assigned to \code{bool}. 
+It is a static type warning if the static type of $e$ may not be assigned to \code{bool}.
 
 \subsection{Switch}
 \LMLabel{switch}
@@ -5804,10 +5817,10 @@ The {\em switch statement} supports dispatching control among a large number of
       label*  \DEFAULT{} `{\escapegrammar :}' statements
     .
  \end{grammar}
- 
+
 \LMHash{}
- Given a switch statement of the form 
- 
+ Given a switch statement of the form
+
 \begin{dartCode}
 \SWITCH{} ($e$) \{
    $label_{11} \ldots label_{1j_1}$ \CASE{} $e_1: s_1$
@@ -5816,9 +5829,9 @@ The {\em switch statement} supports dispatching control among a large number of
    $label_{(n+1)1} \ldots label_{(n+1)j_{n+1}}$ \DEFAULT{}: $s_{n+1}$
 \}
 \end{dartCode}
- 
- or the form 
- 
+
+ or the form
+
 \begin{dartCode}
 \SWITCH{} ($e$) \{
    $label_{11} \ldots label_{1j_1}$ \CASE{} $e_1: s_1$
@@ -5826,27 +5839,27 @@ The {\em switch statement} supports dispatching control among a large number of
    $label_{n1} \ldots label_{nj_n}$ \CASE{} $e_n: s_n$
 \}
 \end{dartCode}
- 
+
  it is a compile-time error if the expressions $e_k$ are not compile-time constants for all  $k \in 1..n$.  It is a compile-time error if the values of the expressions $e_k$ are not either:
  \begin{itemize}
- \item instances of the same class $C$, for all $k \in 1..n$,  or 
- \item instances of a class that implements \cd{int}, for all $k \in 1..n$,  or 
- \item instances of a class that implements \cd{String}, for all $k \in 1..n$. 
+ \item instances of the same class $C$, for all $k \in 1..n$,  or
+ \item instances of a class that implements \cd{int}, for all $k \in 1..n$,  or
+ \item instances of a class that implements \cd{String}, for all $k \in 1..n$.
  \end{itemize}
- 
+
 \commentary{In other words,  all the expressions in the cases evaluate to constants of the exact same user defined class or are of certain known types.  Note that the values of the expressions are known at compile-time, and are independent of any static type annotations.
 }
 
 \LMHash{}
 It is a compile-time error if the class $C$ has an implementation of the operator $==$ other than the one inherited from \code{Object} unless the value of the expression is a string, an integer, literal symbol or the result of invoking a constant constructor of class \cd{Symbol}.
- 
+
  \rationale{
  The prohibition on user defined equality allows us to implement the switch efficiently for user defined types. We could formulate matching in terms of identity instead with the same efficiency. However, if a type defines an equality operator, programmers would find it quite surprising that equal objects did not match.
- 
+
  }
 
 \commentary{
-The \SWITCH{}  statement should only be used in very limited situations (e.g., interpreters or scanners).  
+The \SWITCH{}  statement should only be used in very limited situations (e.g., interpreters or scanners).
 }
 
 \LMHash{}
@@ -5860,9 +5873,9 @@ Execution of a switch statement of the form
    $label_{(n+1)1} \ldots label_{(n+1)j_{n+1}}$ \DEFAULT{}: $s_{n+1}$
 \}
 \end{dartCode}
- 
-or the form 
- 
+
+or the form
+
 \begin{dartCode}
 \SWITCH{} ($e$) \{
    $label_{11} \ldots label_{1j_1}$ \CASE{} $e_1: s_1$
@@ -5874,7 +5887,7 @@ or the form
 proceeds as follows:
 
 \LMHash{}
-The statement \code{\VAR{} id = $e$;} is evaluated, where \code{id} is a variable whose name is distinct from any other variable in the program. In checked mode, it is a run time error if the value of $e$ is not an instance of the same class as the constants $e_1 \ldots e_n$. 
+The statement \code{\VAR{} id = $e$;} is evaluated, where \code{id} is a variable whose name is distinct from any other variable in the program. In checked mode, it is a run time error if the value of $e$ is not an instance of the same class as the constants $e_1 \ldots e_n$.
 
 \commentary{Note that if there are no case clauses ($n = 0$), the type of $e$ does not matter.}
 
@@ -5885,7 +5898,7 @@ Next, the case clause \CASE{} $e_{1}: s_{1}$ is executed if it exists. If \CASE{
 A case clause introduces a new scope, nested in the lexically surrounding scope. The scope of a case clause ends immediately after the case clause's statement list.
 
 \LMHash{}
-Execution of a \CASE{} clause \CASE{} $e_{k}: s_{k}$ of a  switch statement  
+Execution of a \CASE{} clause \CASE{} $e_{k}: s_{k}$ of a  switch statement
 
 \begin{dartCode}
 \SWITCH{} ($e$) \{
@@ -5899,13 +5912,13 @@ Execution of a \CASE{} clause \CASE{} $e_{k}: s_{k}$ of a  switch statement
 proceeds as follows:
 
 \LMHash{}
-The expression \code{$e_k$ == id} is evaluated to an object $o$ which is then subjected to boolean conversion yielding a value $v$. 
+The expression \code{$e_k$ == id} is evaluated to an object $o$ which is then subjected to boolean conversion yielding a value $v$.
 If $v$ is not  \TRUE{} the following case,  \CASE{} $e_{k+1}: s_{k+1}$ is executed if it exists. If  \CASE{} $e_{k+1}: s_{k+1}$ does not exist, then the \DEFAULT{} clause is executed by executing $s_{n+1}$.
 If $v$ is \TRUE{},   let $h$ be the smallest number such that $h \ge k$ and $s_h$ is non-empty. If no such $h$ exists, let $h = n + 1$. The  sequence of statements $s_h$ is then executed.
 If execution reaches the point after $s_h$  then  a runtime error occurs, unless $h = n+1$.
 
 \LMHash{}
-Execution of a \CASE{} clause \CASE{} $e_{k}: s_{k}$ of a  switch statement  
+Execution of a \CASE{} clause \CASE{} $e_{k}: s_{k}$ of a  switch statement
 
 \begin{dartCode}
 \SWITCH{} ($e$) \{
@@ -5918,8 +5931,8 @@ Execution of a \CASE{} clause \CASE{} $e_{k}: s_{k}$ of a  switch statement
 proceeds as follows:
 
 \LMHash{}
-The expression \code{$e_k$ == id} is evaluated to an object $o$ which is then subjected to boolean conversion yielding a value $v$. 
-If $v$ is not  \TRUE{} the following case,  \CASE{} $e_{k+1}: s_{k+1}$ is executed if it exists. 
+The expression \code{$e_k$ == id} is evaluated to an object $o$ which is then subjected to boolean conversion yielding a value $v$.
+If $v$ is not  \TRUE{} the following case,  \CASE{} $e_{k+1}: s_{k+1}$ is executed if it exists.
 If $v$ is \TRUE{},   let $h$ be the smallest integer such that $h \ge k$ and $s_h$ is non-empty. The  sequence of statements $s_h$ is  executed if it exists.
 If execution reaches the point after $s_h$  then  a runtime error occurs, unless $h = n$.
 
@@ -5946,7 +5959,7 @@ The sophistication of the analysis of fall-through is another issue. For now, we
 \rationale{
   Very elaborate code in a case clause is probably bad style in any case, and such code can always be refactored.
 }
- 
+
 \LMHash{}
  It is a static warning if all of the following conditions hold:
  \begin{itemize}
@@ -5959,7 +5972,7 @@ The sophistication of the analysis of fall-through is another issue. For now, we
 In other words, a warning will be issued if a switch statement over an enum is not exhaustive.
 }
 
- 
+
 \subsection{ Rethrow}
 \LMLabel{rethrow}
 
@@ -5972,7 +5985,7 @@ The {\em rethrow statement}  is used to re-raise an exception.
      \RETHROW{}  `{\escapegrammar ;}'
     .
  \end{grammar}
- 
+
 \LMHash{}
 Execution of a \code{\RETHROW{}} statement proceeds as follows:
 
@@ -5999,7 +6012,7 @@ Otherwise, control is transferred to the  innermost enclosing exception handler.
 \commentary{The change in control may result in multiple functions terminating if these functions do not catch the exception via a \CATCH{} or \FINALLY{} clause, both of which introduce a dynamically enclosing exception handler.}
 
 \LMHash{}
-It is a compile-time error if a  \code{\RETHROW{}} statement is not enclosed within an \ON-\CATCH{} clause. 
+It is a compile-time error if a  \code{\RETHROW{}} statement is not enclosed within an \ON-\CATCH{} clause.
 
 
 
@@ -6013,27 +6026,27 @@ The try statement supports the definition of exception handling code in a struct
 {\bf tryStatement:}
       \TRY{} block (onPart+ finallyPart? $|$ finallyPart)
     .
-    
+
  {\bf onPart:}catchPart block;
     \ON{} type catchPart? block
    .
 
 {\bf catchPart:}
-      \CATCH{} `(' identifier (`,' identifier)? `)' 
+      \CATCH{} `(' identifier (`,' identifier)? `)'
     .
 
 {\bf finallyPart:}
       \FINALLY{} block
     .
  \end{grammar}
- 
+
 \LMHash{}
  A try statement consists of a block statement, followed by at least one of:
  \begin{enumerate}
  \item
 A set of \ON{}-\CATCH{} clauses, each of which specifies  (either explicitly or implicitly) the type of exception object to be handled, one or two exception parameters and a block statement.
 \item
-A \FINALLY{} clause, which consists of a block statement. 
+A \FINALLY{} clause, which consists of a block statement.
 \end{enumerate}
 
 \rationale{
@@ -6052,7 +6065,7 @@ An \ON{}-\CATCH{} clause of the form   \code{\ON{} $T$ \CATCH{} ($p_1, p_2$) $s$
 
 
 \LMHash{}
-An \ON{}-\CATCH{} clause of the form  \code{\ON{} $T$ \CATCH{} ($p_1$) $s$} is equivalent to an \ON{}-\CATCH{} clause  \code{\ON{} $T$ \CATCH{} ($p_1, p_2$) $s$} where $p_2$ is an identifier that does not occur anywhere else in the program. 
+An \ON{}-\CATCH{} clause of the form  \code{\ON{} $T$ \CATCH{} ($p_1$) $s$} is equivalent to an \ON{}-\CATCH{} clause  \code{\ON{} $T$ \CATCH{} ($p_1, p_2$) $s$} where $p_2$ is an identifier that does not occur anywhere else in the program.
 
 
 \LMHash{}
@@ -6065,31 +6078,31 @@ An \ON{}-\CATCH{} clause of the form  \code{\CATCH{} ($p$) $s$} is equivalent to
 The {\em active stack trace} is an object whose \code{toString()} method produces a string that is a record of exactly those function activations within the current isolate that had not completed execution at the point where the current exception (\ref{throw}) was thrown.
 %\begin{enumerate}
 %\item Started execution after the currently executing function.
-%\item Had not completed execution at the point where the exception caught by the currently executing  \ON{}-\CATCH{} clause was initially thrown. 
+%\item Had not completed execution at the point where the exception caught by the currently executing  \ON{}-\CATCH{} clause was initially thrown.
 %\commentary{The active stack trace contains the frames between the exception handling code and the original point when an exception is thrown, not where it was rethrown.}
 %\end{enumerate}
 
  \commentary{
-This implies that no synthetic function activations may be added to the trace, nor may any source level activations be omitted. 
+This implies that no synthetic function activations may be added to the trace, nor may any source level activations be omitted.
 This means, for example, that any inlining of functions done as an optimization must not be visible in the trace. Similarly, any synthetic routines used by the implementation must not appear in the trace.
 
 Nothing is said about how any native function calls may be represented in the trace.
  }
- 
+
 \commentary{
 Note that we say nothing about the identity of the stack trace, or what notion of equality is defined for stack traces.
 }
- 
+
 % Sadly, the info below cannot be computed efficiently. It would need to be computed at the throw point, since at latte points it might be destroyed. Native code in calling frames executes relative to the stack pointer, which therefore needs to be reset as each frame is unwound.  This means that the
 % OS kernel can dispose of this stack memory - it is not reliably preserved. And such code must execute if only to test if the exception should be caught or sent onward.
 
 % For each such function activation, the active stack trace includes the name of the function, the bindings of all its formal parameters, local variables and \THIS{}, and the position at which the function was executing.
- 
+
  % Is this controversial? We were thinking of viewing the trace as a List<Invocation>,
  % but that won't capture the receiver or the locals. More generally, we need a standard interface that describes these traces, so one can type the stack trace variable in the catch.
- 
+
  \commentary{The term position should not be interpreted as a line number, but rather as a precise position - the exact character index of the  expression that raised  the exception. }
- 
+
  % A position can be represented via a Token. If we make that part of the core reflection facility, we can state this here.
 
 \LMHash{}
@@ -6103,7 +6116,7 @@ The \ON{}-\CATCH{} clauses are examined in order, starting with $catch_1$, until
 A finally clause \FINALLY{} $s$ defines an exception handler $h$ that executes as follows:
 
 \LMHash{}
-Let $r$ be the current return value (\ref{return}). Then the current return value becomes undefined. Any open streams associated with any asynchronous for loops (\ref{asynchronousFor-in}) and yield-each (\ref{yieldEach}) statements executing within the dynamic scope of $h$ are canceled, in the order of their nesting, innermost first. 
+Let $r$ be the current return value (\ref{return}). Then the current return value becomes undefined. Any open streams associated with any asynchronous for loops (\ref{asynchronousFor-in}) and yield-each (\ref{yieldEach}) statements executing within the dynamic scope of $h$ are canceled, in the order of their nesting, innermost first.
 
 \rationale{
 Streams left open by for loops that were escaped for whatever reason would be canceled at function termination, but it is best to cancel them as soon as possible.
@@ -6115,7 +6128,7 @@ Then the \FINALLY{} clause is executed. Let $m$ be the immediately enclosing fun
 \item
  if there is a dynamically enclosing error handler $g$ defined by a \FINALLY{} clause in $m$, control is transferred to $g$.
  \item
-Otherwise $m$ terminates. 
+Otherwise $m$ terminates.
 \end{itemize}
 
 Otherwise, execution resumes at the end of the try statement.
@@ -6124,7 +6137,7 @@ Otherwise, execution resumes at the end of the try statement.
 Execution of an \ON{}-\CATCH{} clause \code{\ON{} $T$ \CATCH{} ($p_1$, $p_2$)} $s$ of a try statement $t$ proceeds as follows: The statement $s$ is executed in the dynamic scope of the exception handler defined by the finally clause of $t$. Then, the current exception and active stack trace both become undefined.
 
 \LMHash{}
-Execution of a \FINALLY{} clause \FINALLY{} $s$ of a try statement proceeds as follows: 
+Execution of a \FINALLY{} clause \FINALLY{} $s$ of a try statement proceeds as follows:
 
 \LMHash{}
 Let $x$ be the current exception and let $t$ be the active stack trace. Then the current exception and the active stack trace both become undefined. The statement $s$ is executed. Then, if $x$ is defined,  it is rethrown as if by a rethrow statement (\ref{rethrow}) enclosed in a \CATCH{} clause of the form \code{\CATCH{} ($v_x$, $v_t$)} where $v_x$ and $v_t$ are fresh variables bound to $x$ and $t$ respectively.
@@ -6137,20 +6150,20 @@ Execution of a try statement of the form \code{\TRY{} $s_1$ $on-catch_1 \ldots o
 The statement $s_1$ is executed in the dynamic scope of the exception handler defined by the try statement. Then, the \FINALLY{} clause is executed.
 
 \commentary{
-Whether any of the \ON{}-\CATCH{} clauses is executed depends on whether a matching exception has been raised by $s_1$ (see the specification of the throw statement). 
+Whether any of the \ON{}-\CATCH{} clauses is executed depends on whether a matching exception has been raised by $s_1$ (see the specification of the throw statement).
 
-If $s_1$ has raised an exception, it will transfer control to the try statement's handler, which will examine the catch clauses in order for a match as specified above. If no matches are found, the handler will execute the \FINALLY{} clause. 
+If $s_1$ has raised an exception, it will transfer control to the try statement's handler, which will examine the catch clauses in order for a match as specified above. If no matches are found, the handler will execute the \FINALLY{} clause.
 
-If a matching \ON{}-\CATCH{} was found, it will execute first, and then the \FINALLY{} clause will be executed. 
+If a matching \ON{}-\CATCH{} was found, it will execute first, and then the \FINALLY{} clause will be executed.
 
-If an exception is thrown during execution of an \ON{}-\CATCH{} clause, this will transfer control to the handler for the \FINALLY{} clause, causing the \FINALLY{} clause to execute in this case as well. 
+If an exception is thrown during execution of an \ON{}-\CATCH{} clause, this will transfer control to the handler for the \FINALLY{} clause, causing the \FINALLY{} clause to execute in this case as well.
 
-If no exception was raised, the \FINALLY{} clause is also executed. Execution of the \FINALLY{} clause could also raise an exception, which will cause transfer of control to the next enclosing handler. 
+If no exception was raised, the \FINALLY{} clause is also executed. Execution of the \FINALLY{} clause could also raise an exception, which will cause transfer of control to the next enclosing handler.
 }
 
 \LMHash{}
 A try statement of the form \code{\TRY{} $s_1$ $on-catch_1 \ldots on-catch_n$;} is equivalent to the statement \code{\TRY{} $s_1$ $on-catch_1 \ldots on-catch_n$ \FINALLY{} $\{\}$}.
- 
+
 
 \subsection{ Return}
 \LMLabel{return}
@@ -6164,24 +6177,24 @@ The {\em return statement} returns a result to the caller of a synchronous funct
     \RETURN{} expression? `{\escapegrammar ;}' % could do top level here
     .
  \end{grammar}
- 
+
  \commentary{
- Due to \FINALLY{} clauses, the precise behavior of \RETURN{} is a little more involved. Whether the value a return statement is supposed to return is actually returned depends on the behavior of any \FINALLY{} clauses in effect when executing the return. A \FINALLY{} clause may choose to return another value, or throw an exception, or even redirect control flow leading to other returns or throws. All a return statement really does is set a value that is intended to be returned when the function terminates. 
+ Due to \FINALLY{} clauses, the precise behavior of \RETURN{} is a little more involved. Whether the value a return statement is supposed to return is actually returned depends on the behavior of any \FINALLY{} clauses in effect when executing the return. A \FINALLY{} clause may choose to return another value, or throw an exception, or even redirect control flow leading to other returns or throws. All a return statement really does is set a value that is intended to be returned when the function terminates.
  }
 
 \LMHash{}
 The {\em current return value} is a unique value specific to a given function activation. It is undefined unless explicitly set in this specification.
-    
+
 \LMHash{}
 Executing a return statement \code{\RETURN{} $e$;} proceeds as follows:
 
 \LMHash{}
 First the expression $e$ is evaluated, producing an object $o$. Next:
 \begin{itemize}
-\item  
+\item
 The current return value is set to $o$ and the current exception (\ref{throw}) and active stack trace (\ref{try}) become undefined.
 \item
-Let $c$ be the \FINALLY{} clause of the innermost enclosing try-finally statement (\ref{try}), if any. If $c$ is defined, let $h$ be the handler induced by $c$. If $h$ is defined, control is transferred to $h$. 
+Let $c$ be the \FINALLY{} clause of the innermost enclosing try-finally statement (\ref{try}), if any. If $c$ is defined, let $h$ be the handler induced by $c$. If $h$ is defined, control is transferred to $h$.
 \item
 Otherwise execution of the current method terminates.
 \end{itemize}
@@ -6192,15 +6205,15 @@ The enclosing function cannot be marked as generator (i.e, \ASYNC* or \SYNC*), s
 }
 
 \LMHash{}
-Let $T$ be the static type of $e$ and let $f$ be the immediately enclosing function.  
+Let $T$ be the static type of $e$ and let $f$ be the immediately enclosing function.
 
 \LMHash{}
-It is a static type warning if the body of $f$ is marked \ASYNC{} and the type \code{Future$<$flatten(T)$>$} (\ref{functionExpressions}) may not be assigned to the declared return type of $f$.    Otherwise, it is a static type warning if $T$ may not be assigned to the declared return type of $f$. 
+It is a static type warning if the body of $f$ is marked \ASYNC{} and the type \code{Future$<$flatten(T)$>$} (\ref{functionExpressions}) may not be assigned to the declared return type of $f$.    Otherwise, it is a static type warning if $T$ may not be assigned to the declared return type of $f$.
 
 \LMHash{}
 Let $S$ be the runtime type of $o$. In checked mode:
 \begin{itemize}
-\item  If the body of $f$ is marked \ASYNC{} (\ref{functions}) it is a dynamic type error if $o$ is not \NULL{} (\ref{null}) and \code{Future$<$S$>$} is not a subtype of the actual return type  (\ref{actualTypeOfADeclaration}) of $f$.
+\item  If the body of $f$ is marked \ASYNC{} (\ref{functions}) it is a dynamic type error if $o$ is not \NULL{} (\ref{null}) and \code{Future$<$flatten(S)$>$} is not a subtype of the actual return type  (\ref{actualTypeOfADeclaration}) of $f$.
 \item Otherwise, it is a dynamic type error if $o$ is not \NULL{} and the runtime type of $o$ is not a subtype of the actual return type of $f$.
 \end{itemize}
 
@@ -6215,14 +6228,14 @@ It is quite easy to forget to add the factory prefix for a constructor, accident
 It is a compile-time error if a return statement of the form \code{\RETURN{} $e$;} appears in a generator function.
 
 \rationale{
-In the case of a generator function, the value returned by the function is the iterable or stream associated with it, and individual elements are added to that iterable using yield statements, and so returning a value makes no sense. 
+In the case of a generator function, the value returned by the function is the iterable or stream associated with it, and individual elements are added to that iterable using yield statements, and so returning a value makes no sense.
 }
 
 \LMHash{}
 Let $f$ be the function immediately enclosing a return statement of the form \RETURN{}; It is a static warning  $f$ is neither a generator nor a generative constructor and either:
 \begin{itemize}
-\item  $f$ is synchronous and the return type of $f$ may not be assigned to \VOID{} (\ref{typeVoid}) or, 
-\item  $f$ is asynchronous and the return type of $f$ may not be assigned to \code{Future$<$Null$>$}.  
+\item  $f$ is synchronous and the return type of $f$ may not be assigned to \VOID{} (\ref{typeVoid}) or,
+\item  $f$ is asynchronous and the return type of $f$ may not be assigned to \code{Future$<$Null$>$}.
 \end{itemize}
 
  \commentary{
@@ -6240,17 +6253,17 @@ If the immediately enclosing function $f$ is a generator, then:
 \begin{itemize}
 \item
 The current return value is set to \NULL{}.
-\item 
+\item
 Let $c$ be the \FINALLY{} clause of the innermost enclosing try-finally statement, if any. If $c$ is defined,  let $h$ be the handler induced by $c$. If $h$ is defined, control is transferred to $h$.
 \item
-Otherwise, execution of the current method terminates. 
+Otherwise, execution of the current method terminates.
 \end{itemize}
 
 \LMHash{}
 Otherwise the return statement is executed by executing the statement  \code{\RETURN{} \NULL{};} if it occurs inside a method, getter, setter or factory; otherwise, the return statement necessarily occurs inside a generative constructor, in which case it is executed by executing  \code{\RETURN{} \THIS{};}.
 
-\commentary{Despite the fact that \code{\RETURN{};} is executed as if by a \code{\RETURN{} $e$;}, it is important to understand that it is not a static warning to include a statement of the form \code{\RETURN{};} 
-%in a \VOID{} function; neither is it illegal 
+\commentary{Despite the fact that \code{\RETURN{};} is executed as if by a \code{\RETURN{} $e$;}, it is important to understand that it is not a static warning to include a statement of the form \code{\RETURN{};}
+%in a \VOID{} function; neither is it illegal
 in a generative constructor. The rules relate only to the specific syntactic form \code{\RETURN{} $e$;}.
 }
 
@@ -6275,14 +6288,14 @@ A {\em label} is an identifier followed by a colon. A {\em labeled statement} is
 
 \rationale{The sole role of labels is to provide targets for the break (\ref{break}) and continue (\ref{continue}) statements.}
 
-%\Q{Are labels in a separate namespace? Bug 49774299} 
+%\Q{Are labels in a separate namespace? Bug 49774299}
 
  \begin{grammar}
 {\bf label:}
       identifier `{\escapegrammar :}'
     .
  \end{grammar}
- 
+
 \LMHash{}
  The semantics of a labeled statement $L: s$ are identical to those of the statement $s$. The namespace of labels is distinct from the one used for types, functions and variables.
 
@@ -6292,24 +6305,24 @@ The scope of a label that labels a statement $s$ is $s$. The scope of a label th
 \rationale{Labels should be avoided by programmers at all costs. The motivation for including labels in the language is primarily making Dart a better target for code generation.
 }
 
- 
+
 \subsection{ Break}
 \LMLabel{break}
 
 \LMHash{}
-The {\em break statement} consists of the reserved word \BREAK{} and an optional label (\ref{labels}). 
+The {\em break statement} consists of the reserved word \BREAK{} and an optional label (\ref{labels}).
 
 \begin{grammar}
 {\bf breakStatement:}
      \BREAK{} identifier? `{\escapegrammar ;}'
     .
  \end{grammar}
- 
+
 \LMHash{}
-Let $s_b$ be a \BREAK{} statement. If $s_b$ is of the form  \code{\BREAK{} $L$;}, then let $s_E$ be the innermost labeled statement with label $L$ enclosing $s_b$. If $s_b$ is of the form \code{\BREAK{};},  then let $s_E$ be the innermost  \DO{} (\ref{do}), \FOR{} (\ref{for}), \SWITCH{} (\ref{switch}) or \WHILE{} (\ref{while}) statement enclosing  $s_b$. It is a compile-time error if no such statement $s_E$ exists within the innermost function in which  $s_b$ occurs.  Furthermore, let $s_1, \ldots, s_n$ be those \TRY{} statements that are both enclosed in $s_E$ and that enclose  $s_b$, and that have a \FINALLY{} clause. Lastly, let $f_j$ be the \FINALLY{} clause of $s_j, 1 \le j \le n$.   Executing  $s_b$ first executes $f_1, \ldots,  f_n$ in innermost-clause-first  order and then terminates $s_E$. 
+Let $s_b$ be a \BREAK{} statement. If $s_b$ is of the form  \code{\BREAK{} $L$;}, then let $s_E$ be the innermost labeled statement with label $L$ enclosing $s_b$. If $s_b$ is of the form \code{\BREAK{};},  then let $s_E$ be the innermost  \DO{} (\ref{do}), \FOR{} (\ref{for}), \SWITCH{} (\ref{switch}) or \WHILE{} (\ref{while}) statement enclosing  $s_b$. It is a compile-time error if no such statement $s_E$ exists within the innermost function in which  $s_b$ occurs.  Furthermore, let $s_1, \ldots, s_n$ be those \TRY{} statements that are both enclosed in $s_E$ and that enclose  $s_b$, and that have a \FINALLY{} clause. Lastly, let $f_j$ be the \FINALLY{} clause of $s_j, 1 \le j \le n$.   Executing  $s_b$ first executes $f_1, \ldots,  f_n$ in innermost-clause-first  order and then terminates $s_E$.
 
 \LMHash{}
-If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), its associated stream subscription is canceled. Furthermore, let $a_k$ be the set of asynchronous for loops  and yield-each statements (\ref{yieldEach}) enclosing $s_b$ that are enclosed in $s_E , 1 \le k \le m$, where $a_k$ is enclosed in $a_{k+1}$.   The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$, innermost first, so that $a_j$ is canceled before $a_{j+1}$. 
+If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), its associated stream subscription is canceled. Furthermore, let $a_k$ be the set of asynchronous for loops  and yield-each statements (\ref{yieldEach}) enclosing $s_b$ that are enclosed in $s_E , 1 \le k \le m$, where $a_k$ is enclosed in $a_{k+1}$.   The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$, innermost first, so that $a_j$ is canceled before $a_{j+1}$.
 
 
 
@@ -6317,30 +6330,30 @@ If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), its associated
 \LMLabel{continue}
 
 \LMHash{}
-The {\em continue statement} consists of the reserved word \CONTINUE{} and an optional label (\ref{labels}). 
+The {\em continue statement} consists of the reserved word \CONTINUE{} and an optional label (\ref{labels}).
 
 \begin{grammar}
 {\bf continueStatement:}
     \CONTINUE{} identifier? `{\escapegrammar ;}'
         .
- \end{grammar}      
- 
+ \end{grammar}
+
 \LMHash{}
  Let $s_c$ be a \CONTINUE{} statement. If $s_c$ is of the form  \code{\CONTINUE{} $L$;}, then let $s_E$ be the innermost labeled \DO{} (\ref{do}), \FOR{} (\ref{for}) or \WHILE{} (\ref{while}) statement or case clause with label $L$ enclosing $s_c$. If $s_c$ is of the form \code{\CONTINUE{};}  then let $s_E$ be the innermost  \DO{} (\ref{do}), \FOR{} (\ref{for}) or \WHILE{} (\ref{while}) statement enclosing  $s_c$. It is a compile-time error if no such statement or case clause $s_E$ exists within the innermost function in which  $s_c$ occurs.  Furthermore, let $s_1, \ldots, s_n$ be those \TRY{} statements that are both enclosed in $s_E$ and that enclose  $s_c$, and that have a \FINALLY{} clause. Lastly, let $f_j$ be the \FINALLY{} clause of $s_j, 1 \le j \le n$.   Executing  $s_c$ first executes $f_1, \ldots,  f_n$ in innermost-clause-first  order. Then, if $s_E$ is a case clause, control is transferred to the case clause. Otherwise, $s_E$ is necessarily a loop and execution resumes after the last statement in the loop body.
- 
+
  \commentary{
  In a while loop, that would be the boolean expression before the body. In a do loop, it would be the boolean expression after the body. In a for loop, it would be the increment clause.  In other words, execution continues to the next iteration of the loop.
  }
- 
+
 \LMHash{}
- If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), let $a_k$ be the set of asynchronous for loops and yield-each statements (\ref{yieldEach}) enclosing $s_c$ that are enclosed in $s_E , 1 \le k \le m$, where $a_k$ is enclosed in $a_{k+1}$.   The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$, innermost first, so that $a_j$ is canceled before $a_{j+1}$. 
- 
+ If $s_E$ is an asynchronous for loop (\ref{asynchronousFor-in}), let $a_k$ be the set of asynchronous for loops and yield-each statements (\ref{yieldEach}) enclosing $s_c$ that are enclosed in $s_E , 1 \le k \le m$, where $a_k$ is enclosed in $a_{k+1}$.   The stream subscriptions associated with $a_j$ are canceled, $1 \le j \le m$, innermost first, so that $a_j$ is canceled before $a_{j+1}$.
+
  \subsection{ Yield and Yield-Each}
  \LMLabel{yieldAndYieldEach}
- 
+
  \subsubsection{ Yield}
  \LMLabel{yield}
- 
+
 \LMHash{}
  The {\em yield statement} adds an element to the result of a generator function (\ref{functions}).
 
@@ -6357,7 +6370,7 @@ Execution of a statement $s$ of the form \code{\YIELD{} $e$;}  proceeds as follo
 First, the expression $e$ is evaluated to an object $o$. If the enclosing function $m$ is marked \ASYNC* (\ref{functions}) and the stream $u$ associated with $m$ has been paused,  then execution of $m$ is suspended until $u$ is resumed or canceled.
 
 \LMHash{}
-Next, $o$ is added to the iterable or stream associated with the immediately enclosing function. 
+Next, $o$ is added to the iterable or stream associated with the immediately enclosing function.
 
 \LMHash{}
 If the enclosing function $m$ is marked \ASYNC* and the stream $u$ associated with $m$ has been canceled, then let $c$ be the \FINALLY{} clause (\ref{try}) of the innermost enclosing try-finally statement, if any. If $c$ is defined, let $h$ be the handler induced by $c$. If $h$ is defined, control is transferred to $h$. If $h$ is undefined, the immediately enclosing function terminates.
@@ -6378,7 +6391,7 @@ If a \YIELD{} occurred inside an infinite loop and the enclosing function never
 If the enclosing function $m$ is marked \SYNC* (\ref{functions}) then:
 \begin{itemize}
 \item
-Execution of the function $m$ immediately enclosing $s$ is suspended until the nullary method \code{moveNext()} is invoked upon the iterator used to initiate the current invocation of $m$. 
+Execution of the function $m$ immediately enclosing $s$ is suspended until the nullary method \code{moveNext()} is invoked upon the iterator used to initiate the current invocation of $m$.
 \item
 The current call to \code{moveNext()} returns \TRUE.
 \end{itemize}
@@ -6390,18 +6403,18 @@ It is a compile-time error if a yield statement appears in a function that is no
 Let $T$ be the static type of $e$ and let $f$ be the immediately enclosing function.  It is a static type warning if either:
 \begin{itemize}
 \item
- the body of $f$ is marked \ASYNC* and the type \code{Stream$<$T$>$} may not be assigned to the declared return type of $f$. 
+ the body of $f$ is marked \ASYNC* and the type \code{Stream$<$T$>$} may not be assigned to the declared return type of $f$.
  \item
  the body of $f$ is marked \SYNC* and the type \code{Iterable$<$T$>$} may not be assigned to the declared return type of $f$.
- \end{itemize} 
+ \end{itemize}
+
 
- 
  \subsubsection{ Yield-Each}
  \LMLabel{yieldEach}
- 
+
 \LMHash{}
  The {\em yield-each statement} adds a series of values to the result of a generator function (\ref{functions}).
- 
+
  \begin{grammar}
 {\bf yieldEachStatement:}
    \YIELD* expression `{\escapegrammar ;}'
@@ -6412,16 +6425,16 @@ Let $T$ be the static type of $e$ and let $f$ be the immediately enclosing funct
 Execution of a statement $s$ of the form \code{\YIELD* $e$;}  proceeds as follows:
 
 \LMHash{}
-First, the expression $e$ is evaluated to an object $o$. 
+First, the expression $e$ is evaluated to an object $o$.
 
 \LMHash{}
 If the immediately enclosing function $m$ is marked \SYNC* (\ref{functions}), then:
 \begin{enumerate}
 \item It is a dynamic error if the class of $o$ does not implement \code{Iterable}.  Otherwise
-\item The method \cd{iterator} is invoked upon $o$ returning an object $i$. 
+\item The method \cd{iterator} is invoked upon $o$ returning an object $i$.
 \item \label{moveNext} The \cd{moveNext} method of $i$ is invoked on it with no arguments. If \cd{moveNext} returns \FALSE{} execution of $s$ is complete. Otherwise
 \item The getter \cd{current} is invoked on $i$. If the invocation raises an exception $ex$, execution of $s$ throws $ex$. Otherwise, the result $x$ of the getter invocation is added to the iterable associated with $m$.
-Execution of the function $m$ immediately enclosing $s$ is suspended until the nullary method \code{moveNext()} is invoked upon the iterator used to initiate the current invocation of $m$, at which point execution of $s$ continues at \ref{moveNext}. 
+Execution of the function $m$ immediately enclosing $s$ is suspended until the nullary method \code{moveNext()} is invoked upon the iterator used to initiate the current invocation of $m$, at which point execution of $s$ continues at \ref{moveNext}.
 \item
 The current call to \code{moveNext()} returns \TRUE.
 \end{enumerate}
@@ -6439,7 +6452,7 @@ If the stream $u$ associated with $m$ has been canceled, then let $c$ be the \FI
 \item
 Otherwise,  $x$ is added to the stream associated with $m$ in the order it appears in $o$.  The function $m$ may suspend.
 \end{itemize}
-\item If the stream $o$ is done, execution of $s$ is complete. 
+\item If the stream $o$ is done, execution of $s$ is complete.
 \end{itemize}
 
 
@@ -6447,7 +6460,7 @@ Otherwise,  $x$ is added to the stream associated with $m$ in the order it appea
 It is a compile-time error if a yield-each statement appears in a function that is not a generator function.
 
 \LMHash{}
-Let $T$ be the static type of $e$ and let $f$ be the immediately enclosing function.  It is a static type warning if $T$ may not be assigned to the declared return type of $f$.  If $f$ is synchronous it is a static  type warning if $T$ may not be assigned to \code{Iterable}.  If $f$ is asynchronous it is a static  type warning if $T$ may not be assigned to \code{Stream}. 
+Let $T$ be the static type of $e$ and let $f$ be the immediately enclosing function.  It is a static type warning if $T$ may not be assigned to the declared return type of $f$.  If $f$ is synchronous it is a static  type warning if $T$ may not be assigned to \code{Iterable}.  If $f$ is asynchronous it is a static  type warning if $T$ may not be assigned to \code{Stream}.
 
 
 \subsection{ Assert}
@@ -6461,30 +6474,30 @@ An {\em assert statement} is used to disrupt normal execution if a given boolean
    assert `(' conditionalExpression `)' `{\escapegrammar ;}'
       .
 \end{grammar}
-      
+
 \LMHash{}
 The assert statement has no effect in production mode. In checked mode, execution of an assert statement \code{\ASSERT{}($e$);} proceeds as follows:
 
 \LMHash{}
-The conditional expression $e$ is evaluated to an object $o$. If the class of $o$ is a subtype of \code{Function} then let $r$ be the result of invoking $o$ with no arguments. Otherwise, let $r$ be $o$. 
+The conditional expression $e$ is evaluated to an object $o$. If the class of $o$ is a subtype of \code{Function} then let $r$ be the result of invoking $o$ with no arguments. Otherwise, let $r$ be $o$.
 It is a dynamic type error if $o$ is not of type \code{bool} or of type \code{Function}, or if $r$ is not of type \code{bool}.  If $r$ is \FALSE{}, we say that the assertion failed. If $r$ is \TRUE{}, we say that the assertion succeeded. If the assertion succeeded, execution of the assert statement is complete. If the assertion failed, an \code{AssertionError} is thrown.
 
 %\Q{Might be cleaner to define it as \code{if (!$e$) \{\THROW{} \NEW{} AssertionError();\}} (in checked mode only).
 %What about an error message as part of the assert?}
 
 \LMHash{}
- It is a static type warning if the type of $e$ may not be assigned to either  \code{bool} or $() \rightarrow$ \code{bool}.  
+ It is a static type warning if the type of $e$ may not be assigned to either  \code{bool} or $() \rightarrow$ \code{bool}.
 
 \rationale{Why is this a statement, not a built in function call? Because it is handled magically so it has no effect and no overhead in production mode. Also, in the absence of final methods. one could not prevent it being overridden (though there is no real harm in that).  It cannot be viewed as a function call that is being optimized away because the argument might have side effects.
 }
 
-%If a lexically visible declaration named \code{assert} is in scope, an assert statement 
+%If a lexically visible declaration named \code{assert} is in scope, an assert statement
 %\code{\ASSERT{} (e); }
 %is interpreted as an expression statement \code{(assert(e));} .
 
 %\rationale{
 %Since \ASSERT{} is a built-in identifier, one might define a function or method with this name.
-%It is impossible to distinguish as \ASSERT{} statement from a method invocation in such a situation. 
+%It is impossible to distinguish as \ASSERT{} statement from a method invocation in such a situation.
 %One could choose to always interpret such code as an \ASSERT{} statement. Or we could choose to give priority to any lexically visible user defined function.  The former can cause rather puzzling situations, e.g.,}
 
 %\begin{dartCode}
@@ -6505,7 +6518,7 @@ It is a dynamic type error if $o$ is not of type \code{bool} or of type \code{Fu
 \LMLabel{librariesAndScripts}
 
 \LMHash{}
-A Dart program consists of one or more libraries, and may be built out of one or more {\em compilation units}. A compilation unit may be a library or a part (\ref{parts}). 
+A Dart program consists of one or more libraries, and may be built out of one or more {\em compilation units}. A compilation unit may be a library or a part (\ref{parts}).
 
 \LMHash{}
 A library consists of (a possibly empty) set of imports, a set of exports,  and a set of top-level declarations. A top-level declaration is either a class (\ref{classes}), a type alias declaration (\ref{typedef}), a function (\ref{functions}) or a variable declaration (\ref{variables}). The members of a library $L$ are those top level declarations given within $L$.
@@ -6519,14 +6532,14 @@ A library consists of (a possibly empty) set of imports, a set of exports,  and
       typeAlias;
       \EXTERNAL{}? functionSignature `{\escapegrammar ;}';
       \EXTERNAL{}? getterSignature `{\escapegrammar ;}';
-      \EXTERNAL{}? setterSignature `{\escapegrammar ;}';      
+      \EXTERNAL{}? setterSignature `{\escapegrammar ;}';
       functionSignature functionBody;
       returnType? \GET{} identifier functionBody;
       returnType? \SET{} identifier formalParameterList functionBody;
       (\FINAL{} $|$ \CONST{}) type? staticFinalDeclarationList `{\escapegrammar ;}';
       variableDeclaration `{\escapegrammar ;}'
     .
-    
+
     {\bf getOrSet:} \GET{};
       \SET{}
     .
@@ -6545,47 +6558,47 @@ A library consists of (a possibly empty) set of imports, a set of exports,  and
 %      library '\{' libraryBody '\}'
       scriptTag? libraryName? importOrExport* partDirective* topLevelDefinition*
     .
-    
+
     {\bf     scriptTag:}
    `\#!' {\escapegrammar (\~{}NEWLINE)*} NEWLINE
- .    
+ .
 
 {\bf libraryName:}
    metadata \LIBRARY{} identifier (`{\escapegrammar .}' identifier)* `{\escapegrammar ;}'
    .
 
 {\bf importOrExport:}libraryImport ;
-  libraryExport   
+  libraryExport
  \end{grammar}
- 
+
 \LMHash{}
  Libraries may be {\em explicitly named} or {\em implicitly named}. An explicitly named library begins with  the  word \LIBRARY{} (possibly prefaced with any applicable metadata annotations), followed by a qualified identifier that gives the name of the library.
- 
+
  \commentary{
  Technically, each dot and identifier is a separate token and so spaces between them are acceptable. However, the actual library name is the concatenation of the simple identifiers and dots and contains no spaces.
  }
- 
+
 \LMHash{}
-An implicitly named library has the empty string as its name. 
+An implicitly named library has the empty string as its name.
 
  \rationale{
 The name of a library is used to tie it to separately compiled parts of the library (called parts) and  can be used for printing and, more generally, reflection. The name may be relevant for further language evolution.
  }
- 
+
  \commentary{
 Libraries intended for widespread use should avoid name collisions.  Dart's \code{pub} package management system provides a mechanism for doing so.  Each pub package is guaranteed a unique name, effectively enforcing a global namespace.
  }
- 
+
 \LMHash{}
  A library may optionally begin with a {\em script tag}. Script tags are intended for use with scripts (\ref{scripts}).  A script tag can be used to identify the interpreter of the script to whatever computing environment the script is embedded in. The script tag must appear before any whitespace or comments.  A script  tag begins with the characters \#! and ends at the end of the line. Any characters that follow \#!  in the script tag are ignored by the Dart implementation.
- 
+
 \LMHash{}
 Libraries are units of privacy. A private declaration declared within a library $L$ can only be accessed by code within $L$. Any attempt to access a private member declaration from outside $L$ will cause a method, getter or setter lookup failure.
 
 \commentary{Since top level privates are not imported, using the top level privates of another library is never possible. }
 
 \LMHash{}
-The {\em public namespace} of library $L$ is the mapping that maps the simple name of each public top-level member $m$ of $L$ to $m$. 
+The {\em public namespace} of library $L$ is the mapping that maps the simple name of each public top-level member $m$ of $L$ to $m$.
 The scope of a library $L$ consists of the names introduced by all top-level declarations declared in $L$, and the names added by $L$'s imports (\ref{imports}).
 
 
@@ -6593,28 +6606,28 @@ The scope of a library $L$ consists of the names introduced by all top-level dec
 \LMLabel{imports}
 
 \LMHash{}
-An {\em import} specifies a library to be used in the scope of another library. 
+An {\em import} specifies a library to be used in the scope of another library.
 \begin{grammar}
 {\bf libraryImport:}
    metadata importSpecification
     .
- 
+
  {\bf importSpecification:}
     \IMPORT{}  uri (\AS{} identifier)?  combinator* `{\escapegrammar ;}';
      \IMPORT{}  uri \DEFERRED{} \AS{} identifier  combinator* `{\escapegrammar ;}'
     .
-       
+
 {\bf combinator:}\SHOW{} identifierList;
 \HIDE{} identifierList
     .
-    
+
     {\bf identifierList:}
       identifier (, identifier)*
  \end{grammar}
- 
+
 
 \LMHash{}
-An import specifies a URI $x$ where the declaration of an imported library is to be found. 
+An import specifies a URI $x$ where the declaration of an imported library is to be found.
 
 \LMHash{}
 Imports may be {\em deferred} or {\em immediate}. A deferred import is distinguished by the appearance of the built-in identifier \DEFERRED{} after the URI. Any import that is not deferred is immediate.
@@ -6629,10 +6642,10 @@ It is a static warning if the specified URI of a deferred import does not refer
  One cannot detect the problem at compile time because compilation often occurs during execution and  one does not know what the URI refers to.  However the development environment should detect the problem.
  }
 
- 
+
 \LMHash{}
 The {\em current library} is the library currently being compiled. The import modifies the  namespace of the current library in a manner that is determined by the imported library and by the optional elements of  the import.
-     
+
 \LMHash{}
 An immediate import directive $I$ may optionally include a prefix clause of the form \AS{} \code{Id} used to prefix names imported by $I$. A deferred import must include a prefix clause or a compile time error occurs. It is a compile-time error if a prefix used in a deferred import is used in another import clause.
 
@@ -6668,7 +6681,7 @@ After a call succeeds, the name $p$ is mapped to a non-deferred prefix object as
 The effect of a repeated call to \code{$p$.loadLibrary} is as follows:
 \begin{itemize}
 \item
-If another call to \code{$p$.loadLibrary} has already succeeded, the repeated call also succeeds. 
+If another call to \code{$p$.loadLibrary} has already succeeded, the repeated call also succeeds.
 Otherwise,
 \item
 If another call to  to \code{$p$.loadLibrary} has failed:
@@ -6700,23 +6713,23 @@ If  the URI that is the value of $s_1$ has not yet been accessed by an import or
 \LMHash{}
 Let $NS_0$ be the exported namespace (\ref{exports}) of $B$. Then, for each combinator clause $C_i, i \in 1..n$ in $I$:
 \begin{itemize}
-\item If $C_i$ is of the form 
+\item If $C_i$ is of the form
 
-\code{\SHOW{} $id_1, \ldots, id_k$} 
+\code{\SHOW{} $id_1, \ldots, id_k$}
 
 then let $NS_i = \SHOW{}([id_1, \ldots, id_k], NS_{i-1}$)
 
 where $show(l,n)$ takes a list of identifiers $l$ and a namespace $n$, and produces a namespace that maps each name in $l$ to the same element that $n$ does. Furthermore, for each name $x$ in $l$, if $n$ defines the name  $x=$ then the new namespace maps $x=$ to the same element that $n$ does. Otherwise the resulting mapping is undefined.
-  
-\item If $C_i$ is of the form 
 
-\code{\HIDE{} $id_1, \ldots, id_k$} 
+\item If $C_i$ is of the form
 
-then let $NS_i = \HIDE{}([id_1, \ldots, id_k], NS_{i-1}$) 
+\code{\HIDE{} $id_1, \ldots, id_k$}
 
-where $hide(l, n)$ takes a list of identifiers $l$ and a namespace $n$, and produces a namespace that is identical to $n$ except that for each name $k$ in $l$, $k$ and $k=$ are undefined. 
+then let $NS_i = \HIDE{}([id_1, \ldots, id_k], NS_{i-1}$)
+
+where $hide(l, n)$ takes a list of identifiers $l$ and a namespace $n$, and produces a namespace that is identical to $n$ except that for each name $k$ in $l$, $k$ and $k=$ are undefined.
 \end{itemize}
- 
+
 \LMHash{}
 Next, if $I$ includes a prefix clause of the form \AS{} $p$, let $NS =  NS_n \cup \{p: prefixObject(NS_n)\}$ where $prefixObject(NS_n)$ is a {\em prefix object} for the namespace $NS_n$, which is an object that has the following members:
 
@@ -6748,7 +6761,7 @@ a top-level declaration with the name $k$ exists in $L$, OR
 \rationale{The greatly increases the chance that a member can be added to a library without breaking its importers.}
 
 \LMHash{}
-A {\em system library} is a library that is part of the Dart implementation. Any other library is a {\em non-system library}. If a name $N$ is referenced by a library $L$ and $N$ would be introduced into the top level scope of $L$ by 
+A {\em system library} is a library that is part of the Dart implementation. Any other library is a {\em non-system library}. If a name $N$ is referenced by a library $L$ and $N$ would be introduced into the top level scope of $L$ by
 imports of two libraries, $L_1$ and $L_2$, and the exported namespace of $L_1$ binds $N$ to a declaration originating in a system library:
 
 %an import of a  system library and an import of a non-system library:
@@ -6767,7 +6780,7 @@ It is recommended that tools that deploy Dart code produce output in which all i
 If a name $N$ is referenced by a library $L$ and $N$ is  introduced into  the top level scope of $L$ by more than one import, and not all the imports denote the same declaration, then:
 \begin{itemize}
 \item A static warning occurs.
-\item If $N$ is referenced as a function, getter or setter, a \code{NoSuchMethodError} is thrown. 
+\item If $N$ is referenced as a function, getter or setter, a \code{NoSuchMethodError} is thrown.
 \item  If $N$ is referenced as a type, it is treated as a malformed type.
 
 \end{itemize}
@@ -6780,7 +6793,7 @@ It is neither an error nor a warning if  $N$ is introduced by two or more import
 }
 
 \rationale{
-The policy above makes libraries more robust in the face of additions made to their imports.  
+The policy above makes libraries more robust in the face of additions made to their imports.
 
 A clear distinction needs to be made between this approach, and seemingly similar policies with respect to classes or interfaces.  The use of a class or interface, and of its members, is separate from its declaration. The usage and declaration may occur in widely separated places in the code, and may in fact be authored by different people or organizations.  It is important that errors are given at the offending declaration so that the party that receives the error can respond to it a meaningful way.
 
@@ -6797,14 +6810,14 @@ A widely disseminated library should be given a name that will not conflict with
 }
 
 \commentary{Note that no errors or warnings are given if one hides or shows a name that is not in a namespace.}
-\rationale{  
+\rationale{
 This prevents situations where removing a name from a library would cause breakage of a client library.
 }
 
 \LMHash{}
 The dart core library \code{dart:core} is implicitly imported into every dart library other than itself via an  import clause of the form
 
-\code{\IMPORT{}  `dart:core';} 
+\code{\IMPORT{}  `dart:core';}
 
 unless the importing library explicitly imports \code{dart:core}.
 
@@ -6813,7 +6826,7 @@ Any import of \code{dart:core}, even if restricted via \SHOW{}, \HIDE{} or \AS{}
 }
 
 \rationale{
-It would be nice if there was nothing special about \code{dart:core}. However, its use is pervasive, which leads to the decision to import it automatically.  However, some library $L$  may wish to define entities with names used by \code{dart:core} (which it can easily do, as the names declared by a library take precedence). Other libraries may wish to use $L$ and may want to use members of $L$ that conflict with the core library without having to use a prefix and without encountering warnings. The above rule makes this possible, essentially canceling \code{dart:core}'s special treatment by means of yet another special rule. 
+It would be nice if there was nothing special about \code{dart:core}. However, its use is pervasive, which leads to the decision to import it automatically.  However, some library $L$  may wish to define entities with names used by \code{dart:core} (which it can easily do, as the names declared by a library take precedence). Other libraries may wish to use $L$ and may want to use members of $L$ that conflict with the core library without having to use a prefix and without encountering warnings. The above rule makes this possible, essentially canceling \code{dart:core}'s special treatment by means of yet another special rule.
 }
 
 \subsection{Exports}
@@ -6827,9 +6840,9 @@ A library $L$ exports a namespace (\ref{scoping}), meaning that the declarations
    metadata \EXPORT{}  uri  combinator* `{\escapegrammar ;}'
     .
  \end{grammar}
- 
+
 \LMHash{}
- An export specifies a URI $x$ where the declaration of an exported library is to be found.  It is a compile-time error if  the specified URI does not refer to a library declaration.  
+ An export specifies a URI $x$ where the declaration of an exported library is to be found.  It is a compile-time error if  the specified URI does not refer to a library declaration.
 
 \LMHash{}
 We say that a name {\em is exported by a library} (or equivalently, that a library {\em exports a name}) if the name is in the library's exported namespace. We say that a declaration {\em is exported by a library} (or equivalently, that a library {\em exports a declaration}) if the declaration is in the library's exported namespace.
@@ -6853,17 +6866,17 @@ If  the URI that is the value of $s_1$ has not yet been accessed by an import or
 \LMHash{}
 Let $NS_0$ be the exported namespace of $B$. Then, for each combinator clause $C_i, i \in 1..n$ in $E$:
 \begin{itemize}
-\item If $C_i$ is of the form \code{\SHOW{} $id_1, \ldots, id_k$} then let 
+\item If $C_i$ is of the form \code{\SHOW{} $id_1, \ldots, id_k$} then let
 
-$NS_i = \SHOW{}([id_1, \ldots, id_k], NS_{i-1}$).  
-\item If $C_i$ is of the form \code{\HIDE{} $id_1, \ldots, id_k$} 
+$NS_i = \SHOW{}([id_1, \ldots, id_k], NS_{i-1}$).
+\item If $C_i$ is of the form \code{\HIDE{} $id_1, \ldots, id_k$}
 
-then let $NS_i = \HIDE{}([id_1, \ldots, id_k], NS_{i-1}$). 
+then let $NS_i = \HIDE{}([id_1, \ldots, id_k], NS_{i-1}$).
 \end{itemize}
 
 \LMHash{}
 For each
-entry mapping key $k$ to declaration $d$ in $NS_n$ an entry mapping $k$ to $d$ is added to the exported namespace of $L$ unless a  top-level declaration with the name $k$ exists in $L$.  
+entry mapping key $k$ to declaration $d$ in $NS_n$ an entry mapping $k$ to $d$ is added to the exported namespace of $L$ unless a  top-level declaration with the name $k$ exists in $L$.
 
 \LMHash{}
 If a name $N$ is referenced by a library $L$ and $N$ would be introduced into the exported namespace of $L$ by exports of two libraries, $L_1$ and $L_2$, and the exported namespace of $L_1$ binds $N$ to a declaration originating in a system library:
@@ -6889,14 +6902,14 @@ It is a compile-time error if a name $N$ is re-exported by a library $L$ and $N$
 \LMLabel{parts}
 
 \LMHash{}
-A library may be divided into {\em parts}, each of which can be stored in a separate location. A library identifies its parts by listing them via \PART{} directives. 
+A library may be divided into {\em parts}, each of which can be stored in a separate location. A library identifies its parts by listing them via \PART{} directives.
 
 \LMHash{}
 A {\em part directive} specifies a URI where a Dart compilation unit that should be incorporated into the current library may be found.
 
 \begin{grammar}
 {\bf partDirective:}
-   metadata \PART{}   uri `{\escapegrammar ;}' 
+   metadata \PART{}   uri `{\escapegrammar ;}'
     .
 
 {\bf partHeader:}
@@ -6925,22 +6938,22 @@ A script $S$ may be executed as follows:
 First, $S$ is compiled as a library as specified above. Then, the top-level function \code{main} that is in the exported namespace of $S$ is invoked. If \code{main} has no positional parameters, it is invoked with no arguments. Otherwise if \code{main} has exactly one positional parameter, it is invoked with a single actual argument whose runtime type implements \code{List$<$String$>$}.  Otherwise \code{main} is invoked with the following two actual arguments:
 \begin{enumerate}
 \item An object whose runtime type implements \code{List$<$String$>$}.
-\item The initial message of the current isolate $i$ as determined by the invocation of \code{Isolate.spawnUri} that spawned $i$. 
+\item The initial message of the current isolate $i$ as determined by the invocation of \code{Isolate.spawnUri} that spawned $i$.
 \end{enumerate}
 
 \LMHash{}
 It is a run time error if $S$ does not declare or export either:
 \begin{itemize}
-\item  A top-level function named  \code{main}, or 
+\item  A top-level function named  \code{main}, or
 \item A top-level getter named  \code{main} that returns a function.
 \end{itemize}
 
 \commentary {
-Note that if \code{main} requires more than two arguments, a run time error will occur. 
+Note that if \code{main} requires more than two arguments, a run time error will occur.
 }
 
 \rationale{
-The names of scripts are optional, in the interests of interactive, informal use. However, any script of long term value should be given a name as a matter of good practice. 
+The names of scripts are optional, in the interests of interactive, informal use. However, any script of long term value should be given a name as a matter of good practice.
 }
 
 \commentary {
@@ -6961,26 +6974,26 @@ URIs are specified by means of string literals:
 
 \LMHash{}
 It is a compile-time error if  the string literal $x$ that describes a URI is not a compile-time constant, or if $x$ involves string interpolation.
- 
+
 \LMHash{}
-This specification does not discuss the interpretation of URIs, with the following exceptions. 
- 
+This specification does not discuss the interpretation of URIs, with the following exceptions.
+
  \rationale{
  The interpretation of URIs is mostly left to the surrounding computing environment. For example, if Dart is running in a web browser, that browser will likely interpret some URIs. While it might seem attractive to specify, say, that URIs are interpreted with respect to a standard such as IETF RFC 3986, in practice this will usually depend on the browser and cannot be relied upon.
  }
- 
+
 \LMHash{}
-A URI of the form \code{dart:$s$} is interpreted as a reference to a system library (\ref{imports}) $s$. 
- 
+A URI of the form \code{dart:$s$} is interpreted as a reference to a system library (\ref{imports}) $s$.
+
 \LMHash{}
 A URI of the form \code{package:$s$} is interpreted in an implementation specific manner.
 
 \rationale{
-The intent is that, during development, Dart programmers can rely on a package manager to find elements of their program. 
+The intent is that, during development, Dart programmers can rely on a package manager to find elements of their program.
 }
 
 \LMHash{}
-Otherwise, any relative URI is interpreted as relative to the location of the current library. All further interpretation of URIs is implementation dependent. 
+Otherwise, any relative URI is interpreted as relative to the location of the current library. All further interpretation of URIs is implementation dependent.
 
 \commentary{This means it is dependent on the embedder.}
 
@@ -7006,7 +7019,7 @@ Static type annotations are used in variable declarations (\ref{variables}) (inc
     .
 
 {\bf typeName:}
-      qualified 
+      qualified
     .
 
 {\bf typeArguments:}
@@ -7021,7 +7034,7 @@ Static type annotations are used in variable declarations (\ref{variables}) (inc
 \LMHash{}
 A Dart implementation must provide a static checker that detects and reports exactly those situations this specification identifies as static warnings and only those situations. However:
 \begin{itemize}
-\item Running  the static checker on a program $P$ is not required for compiling and running $P$.  
+\item Running  the static checker on a program $P$ is not required for compiling and running $P$.
 \item Running the static checker on a program $P$ must not prevent successful compilation of $P$ nor may it prevent the execution of $P$, regardless of whether any static warnings occur.
 \end{itemize}
 
@@ -7035,17 +7048,17 @@ A type $T$ is {\em malformed} iff:
 \begin{itemize}
 \item $T$ has the form $id$ or the form $prefix.id$, and in the enclosing lexical scope, the name $id$ (respectively $prefix.id$) does not denote a type.
 \item $T$ denotes a type variable in the enclosing lexical scope, but occurs in the signature or body of a static member.
-\item $T$ is a parameterized type of the form $G<S_1, \ldots , S_n>$, and  $G$ is malformed. 
+\item $T$ is a parameterized type of the form $G<S_1, \ldots , S_n>$, and  $G$ is malformed.
 \item $T$ denotes declarations that were imported from multiple imports clauses.
-%Either $G$ or $S_i,  i \in 1.. n$ are malformed. 
+%Either $G$ or $S_i,  i \in 1.. n$ are malformed.
  % \item  $G$ is not a generic type with $n$ type parameters.
-%  \item Let $T_i$ be the type parameters of $G$ (if any) and let $B_i$ be the bound of $T_i,  i \in 1.. n$, and $S_i$ is not a subtype of $[S_1,  \ldots, S_n/T_1, \ldots, T_n]B_i,   i \in 1.. n$. 
+%  \item Let $T_i$ be the type parameters of $G$ (if any) and let $B_i$ be the bound of $T_i,  i \in 1.. n$, and $S_i$ is not a subtype of $[S_1,  \ldots, S_n/T_1, \ldots, T_n]B_i,   i \in 1.. n$.
 %  \end{itemize}
 \end{itemize}
 
 \LMHash{}
  Any use of a malformed  type gives rise to a static warning. A malformed type is then interpreted as \DYNAMIC{} by the static type checker and the runtime unless explicitly specified otherwise.
-  
+
  \rationale{
 This ensures that the developer is spared a series of cascading warnings as the malformed type interacts with other types.
 }
@@ -7057,11 +7070,11 @@ It is a static warning to use a deferred type in a type annotation, type test, t
 % Now, when passed to a generic, p.T also has to be treated as dynamic - otherwise we have to fail immediately. Where do we say that? And how does this fit with idea that as a type object it fails? Should we say that the accessor on p returns dynamic instead of failing? Do we distinguish its use in a constructor vs its use in an annotation? It's not that we evaluate type objects in constructor args - these cannot represent parameterized types.
 
 
-\subsubsection{Type Promotion}   
+\subsubsection{Type Promotion}
 \LMLabel{typePromotion}
 
 \LMHash{}
-The static type system ascribes a static type to every expression.  In some cases, the types of local variables and formal parameters may be promoted from their declared types based on control flow. 
+The static type system ascribes a static type to every expression.  In some cases, the types of local variables and formal parameters may be promoted from their declared types based on control flow.
 
 \LMHash{}
 We say that a variable $v$ is known to have type $T$ whenever we allow the type of $v$ to be promoted. The exact circumstances when type promotion is allowed are given in the relevant sections of the specification (\ref{logicalBooleanExpressions}, \ref{conditional} and \ref{if}).
@@ -7088,11 +7101,11 @@ Clearly, if a deferred type has not yet been loaded, it is impossible to do a co
 %It is a run-time type error to access an undeclared type outside .
 
 \LMHash{}
-%It is a dynamic type error if a malformed type is used in a subtype test.  
-In checked mode, it is a dynamic type error if a deferred, malformed or malbounded (\ref{parameterizedTypes}) 
-type is used in a subtype test.  
+%It is a dynamic type error if a malformed type is used in a subtype test.
+In checked mode, it is a dynamic type error if a deferred, malformed or malbounded (\ref{parameterizedTypes})
+type is used in a subtype test.
 
-%In production mode, an undeclared type is treated as an instance of type \DYNAMIC{}. 
+%In production mode, an undeclared type is treated as an instance of type \DYNAMIC{}.
 
 \commentary{Consider the following program}
 
@@ -7108,7 +7121,7 @@ main() \{
 
 \commentary{
 The type of the formal parameter of $f$ is $foo$, which is undeclared in the lexical scope. This will lead to a static type warning. At runtime the program will print \cd{yoyoma}, because $foo$ is treated as \DYNAMIC{}.
-%fail when executing the type test on the first line of $main()$ because it leads to a subtype comparison involving a malformed type ($foo$). 
+%fail when executing the type test on the first line of $main()$ because it leads to a subtype comparison involving a malformed type ($foo$).
 
 As another example take}
 
@@ -7116,7 +7129,7 @@ As another example take}
 \VAR{} i;
 i  j; //  a variable j of type i (supposedly)
 main() \{
-     j =  'I am not an i'; 
+     j =  'I am not an i';
 \}
 \end{dartCode}
 
@@ -7135,13 +7148,13 @@ Here is an example involving malbounded types:
 
 \CLASS{} A$<$T$>$ \IMPLEMENTS{} J,  I$<$T$>$ // type warning: T is not a subtype of num
 \{ ...
-\} 
+\}
 \end{dartCode}
 
 \commentary{Given the declarations above, the following}
 
 \begin{dartCode}
-I x = \NEW{} A$<$String$>$(); 
+I x = \NEW{} A$<$String$>$();
 \end{dartCode}
 
 \commentary{
@@ -7149,11 +7162,11 @@ will cause a dynamic type error in checked mode, because the assignment requires
 }
 
 \begin{dartCode}
-J x = \NEW{} A$<$String$>$(); 
+J x = \NEW{} A$<$String$>$();
 \end{dartCode}
 
 \commentary{
-does not cause a dynamic error, as there is no need to test against \code{I$<$String$>$} in this case. 
+does not cause a dynamic error, as there is no need to test against \code{I$<$String$>$} in this case.
 Similarly, in production mode
 }
 
@@ -7183,7 +7196,7 @@ A {\em type alias} declares a name for a type expression.
 {\bf typeAlias:}
  	metadata  \TYPEDEF{} typeAliasBody
 	.
-	
+
 {\bf typeAliasBody:}
 	functionTypeAlias
 	.
@@ -7191,22 +7204,22 @@ A {\em type alias} declares a name for a type expression.
 {\bf functionTypeAlias:}
        functionPrefix  typeParameters? formalParameterList '{\escapegrammar ;}'
     .
-    
+
     {\bf functionPrefix:}
     returnType? identifier
     .
-    
+
  \end{grammar}
- 
+
 \LMHash{}
  The effect of a type alias of the form  \code{\TYPEDEF{} $T$ $id (T_1$ $p_1, \ldots, T_n$ $p_n, [T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$ $p_{n+k}])$} declared in a library $L$ is is to introduce the name $id$ into the scope of $L$, bound to the function type $(T_1, \ldots, T_n, [T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$ $p_{n+k}])  \rightarrow T$.  The effect of a type alias of the form   \code{\TYPEDEF{} $T$ $id (T_1$ $p_1, \ldots, T_n$ $p_n, \{T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$ $p_{n+k}\})$} declared in a library $L$ is is to introduce the name $id$ into the scope of $L$, bound to the function type $(T_1, \ldots, T_n, \{T_{n+1}$ $p_{n+1}, \ldots, T_{n+k}$ $p_{n+k}\})  \rightarrow T$. . In either case, iff no return type is specified, it is taken to be \DYNAMIC{}. Likewise, if a type annotation is omitted on a formal parameter, it is taken to be \DYNAMIC{}.
- 
+
 \LMHash{}
-It is a compile-time error if any default values are specified in the signature of a function type alias. 
-%A typedef may only refer to itself  via the bounds of its generic parameters. 
+It is a compile-time error if any default values are specified in the signature of a function type alias.
+%A typedef may only refer to itself  via the bounds of its generic parameters.
 Any  self reference in a typedef, either directly, or recursively via another typedef, is a compile time error.
-%via a chain of references that does not include a class declaration.  
- 
+%via a chain of references that does not include a class declaration.
+
 
 
 \subsection{Interface Types}
@@ -7267,9 +7280,9 @@ $S$ is a supertype of $T$, written $S :> T$, iff $T$ is a subtype of $S$.
 \commentary{The supertypes of an interface are its direct supertypes and their supertypes. }
 
 \LMHash{}
-An interface type $T$ may be assigned to a type $S$, written  $T \Longleftrightarrow S$, iff either $T <: S$ or $S <: T$. 
+An interface type $T$ may be assigned to a type $S$, written  $T \Longleftrightarrow S$, iff either $T <: S$ or $S <: T$.
 
-\rationale{This rule may surprise readers accustomed to conventional typechecking. The intent of the $\Longleftrightarrow$ relation is not to ensure that an assignment is correct. Instead, it aims to only flag assignments that are almost certain to be erroneous, without precluding assignments that may work. 
+\rationale{This rule may surprise readers accustomed to conventional typechecking. The intent of the $\Longleftrightarrow$ relation is not to ensure that an assignment is correct. Instead, it aims to only flag assignments that are almost certain to be erroneous, without precluding assignments that may work.
 
 For example, assigning a value of static type Object to a variable with static type String, while not guaranteed to be correct, might be fine if the runtime value happens to be a string.
 }
@@ -7278,7 +7291,7 @@ For example, assigning a value of static type Object to a variable with static t
 \LMLabel{functionTypes}
 
 \LMHash{}
-Function types come in two variants: 
+Function types come in two variants:
 \begin{enumerate}
 \item
 The types of functions that only have positional parameters.  These have the general form $(T_1, \ldots, T_n, [T_{n+1} \ldots, T_{n+k}]) \rightarrow T$.
@@ -7297,7 +7310,7 @@ The types of functions with named  parameters. These have the general form $(T_1
 %\end{enumerate}
 
 \LMHash{}
-%A function type $(T_1, \ldots T_n, [T_{n+1}  \ldots, T_{n+k}]) \rightarrow T$ is a subtype of the 
+%A function type $(T_1, \ldots T_n, [T_{n+1}  \ldots, T_{n+k}]) \rightarrow T$ is a subtype of the
 % the line below revises the rule to be more liberal
 A function type $(T_1, \ldots T_{k}, [T_{k+1}  \ldots, T_{n+m}]) \rightarrow T$ is a subtype of the
 function type $(S_1, \ldots, S_{k+j}, [S_{k+j+1} \ldots, S_{n}]) \rightarrow S$, if all of the following conditions are met:
@@ -7322,7 +7335,7 @@ A function type $(T_1, \ldots T_n, \{T_{x_1}$ $x_1, \ldots, T_{x_k}$ $x_k\}) \ri
 \item $\forall i \in 1 .. n, T_i \Longleftrightarrow S_i$.
 \item $k \ge m$ and $y_i \in \{x_1,  \ldots, x_k\}, i \in 1 .. m$.
 %\{x_1,  \ldots, x_k\}$ is a superset of $\{y_1,  \ldots, y_m\}$.
-\item For all $y_i \in \{y_1,  \ldots, y_m\}, y_i = x_j \Rightarrow T_j \Longleftrightarrow S_i$
+\item For all $y_i \in \{y_1,  \ldots, y_m\}, y_i = x_j \Rightarrow T_{x_j} \Longleftrightarrow S_{y_i}$
 \end{enumerate}
 
 %In addition, a function type $(T_1, \ldots, Tn, [T_{n+1} x_{n+1}, \ldots, T_{n+k} x_{n+k}]) \rightarrow T$ is a subtype of the function type $(T_1, \ldots, T_n, T_{n+1} , [T_{n+2} x_{n+2}, \ldots, T_{n+k} x_{n+k}]) \rightarrow T$.
@@ -7332,7 +7345,7 @@ A function type $(T_1, \ldots T_n, \{T_{x_1}$ $x_1, \ldots, T_{x_k}$ $x_k\}) \ri
 %We write $(T_1, \ldots, T_n) \rightarrow T$ as a shorthand for the type $(T_1, \ldots, T_n, []) \rightarrow T$.
 
 %The rules above need to be sanity checked, but the intent is that we view functions with rest parameters as having type $(T_1, ..., T_n, [\_{Tn+1}[] \_]) \rightarrow T$, where \_ is some magical identifier. Then the rules above may cover everything.
-% This is wrong - from the outside, the type takes an unbounded sequence of types, not a list. This can be modeled as $(T_1, \ldots, T_n, [T_{n+1}, \_ \ldots, T_{n+k} \_]) \rightarrow T$ for some finite $k$. 
+% This is wrong - from the outside, the type takes an unbounded sequence of types, not a list. This can be modeled as $(T_1, \ldots, T_n, [T_{n+1}, \_ \ldots, T_{n+k} \_]) \rightarrow T$ for some finite $k$.
 
 \LMHash{}
 In addition, the following subtype rules apply:
@@ -7351,7 +7364,7 @@ The naive reader might conclude that, since it is not legal to declare a functio
 }
 
 \LMHash{}
-A function type $T$ may be assigned to a function type $S$, written  $T \Longleftrightarrow S$, iff  $T <: S$. 
+A function type $T$ may be assigned to a function type $S$, written  $T \Longleftrightarrow S$, iff  $T <: S$.
 
 \LMHash{}
 % ensure that Object  and dynamic may be assign dot a function type
@@ -7398,7 +7411,7 @@ Furthermore, if $F$ is a function type, $F << \code{Function}$.
 \LMLabel{typeDynamic}
 
 \LMHash{}
-The type  \DYNAMIC{}  denotes the unknown type. 
+The type  \DYNAMIC{}  denotes the unknown type.
 
 \LMHash{}
 If no static type annotation has been provided the type system assumes the declaration has the unknown type. If a generic type is used but type arguments are not provided, then the  type arguments default to the unknown type.
@@ -7410,11 +7423,11 @@ If no static type annotation has been provided the type system assumes the decla
 Type  \DYNAMIC{} has methods for every possible identifier and arity, with every possible combination of named parameters. These methods all have  \DYNAMIC{} as their return type, and their formal parameters all have type  \DYNAMIC{}.
 Type  \DYNAMIC{} has properties for every possible identifier. These properties all have type  \DYNAMIC{}.
 
-\rationale{From a usability perspective, we want to ensure that the checker does not issue errors everywhere an unknown type is used. The definitions above ensure that no secondary errors are reported when accessing an unknown type. 
+\rationale{From a usability perspective, we want to ensure that the checker does not issue errors everywhere an unknown type is used. The definitions above ensure that no secondary errors are reported when accessing an unknown type.
 
 The current rules say that missing type arguments are treated as if they were the type  \DYNAMIC{}.  An alternative is to consider them as meaning \code{Object}.  This would lead to earlier error detection in checked mode, and more aggressive errors during static typechecking. For example:
 
-(1)  \code{typedAPI(G\lt{String}\gt g)\{...\}} 
+(1)  \code{typedAPI(G\lt{String}\gt g)\{...\}}
 
 
 (2)  \code{typedAPI(new G()); }
@@ -7433,19 +7446,19 @@ What of static checking? Surely we would want to flag (2) when users have explic
 The name \DYNAMIC{} denotes a \cd{Type} object even though \DYNAMIC{} is not a class.
 
 %\rationale {
-%Type objects reify the runtime types of instances. No instance ever has type \DYNAMIC{}. 
+%Type objects reify the runtime types of instances. No instance ever has type \DYNAMIC{}.
 %}
 
 \subsection{Type Void}
 \LMLabel{typeVoid}
 
 \LMHash{}
-The special type \VOID{} may only be used as the return type of a function: it is a compile-time error to use \VOID{} in any other context. 
+The special type \VOID{} may only be used as the return type of a function: it is a compile-time error to use \VOID{} in any other context.
 
 \commentary{
 For example, as a type argument, or as the type of a variable or parameter
 
-Void is not an interface type. 
+Void is not an interface type.
 
 The only subtype relations that pertain to void are therefore:
 \begin{itemize}
@@ -7468,31 +7481,31 @@ On the other hand, it is possible to return the result of a void method from wit
 
 \rationale {
 It is syntacticly illegal to use \VOID{} as an expression, and it would make no sense to do so.
-Type objects reify the runtime types of instances. No instance ever has type \VOID{}.  
+Type objects reify the runtime types of instances. No instance ever has type \VOID{}.
 }
 
 
 
 \subsection{Parameterized Types}
-\LMLabel{parameterizedTypes} 
+\LMLabel{parameterizedTypes}
 
 \LMHash{}
 A {\em parameterized type} is an invocation of a generic type declaration.
 
 \LMHash{}
-Let $T$ be a parameterized type  $G<S_1,  \ldots, S_n>$. If $G$ is not a generic type, the type arguments $S_i$, $1 \le i \le n$ are discarded. If $G$ has $m \ne n$ type parameters, $T$ is treated as as a parameterized type with $m$ arguments, all of which are \DYNAMIC{}. 
+Let $T$ be a parameterized type  $G<S_1,  \ldots, S_n>$. If $G$ is not a generic type, the type arguments $S_i$, $1 \le i \le n$ are discarded. If $G$ has $m \ne n$ type parameters, $T$ is treated as as a parameterized type with $m$ arguments, all of which are \DYNAMIC{}.
 
-\commentary{In short, any arity mismatch results in all type arguments being dropped, and replaced with the correct number of type arguments, all set to \DYNAMIC{}. Of course, a static warning will be issued. 
+\commentary{In short, any arity mismatch results in all type arguments being dropped, and replaced with the correct number of type arguments, all set to \DYNAMIC{}. Of course, a static warning will be issued.
 }
 
 \LMHash{}
 Otherwise, let
- $T_i$ be the type parameters of $G$ and let $B_i$ be the bound of $T_i,  i \in 1.. n$,. $T$ is {\em malbounded} iff either $S_i$ is malbounded  or $S_i$ is not a subtype of $[S_1,  \ldots, S_n/T_1, \ldots, T_n]B_i,   i \in 1.. n$. 
- 
+ $T_i$ be the type parameters of $G$ and let $B_i$ be the bound of $T_i,  i \in 1.. n$,. $T$ is {\em malbounded} iff either $S_i$ is malbounded  or $S_i$ is not a subtype of $[S_1,  \ldots, S_n/T_1, \ldots, T_n]B_i,   i \in 1.. n$.
+
 \commentary{
 Note, that, in checked mode, it is a dynamic type error if a malbounded type is used in a type test as specified in \ref{dynamicTypeSystem}.
 }
- 
+
 \LMHash{}
 Any use of a malbounded type gives rise to a static warning.
 
@@ -7526,14 +7539,14 @@ Let $T$ be the declared type of a declaration $d$, as it appears in the program
 
 \LMHash{}
 % does this diverge in some cases?
-Given two interfaces $I$ and $J$, let $S_I$ be the set of superinterfaces of $I$,  let $S_J$ be the set of superinterfaces of $J$ and let $S =  (I \cup S_I) \cap (J \cup S_J)$.  Furthermore, we define $S_n = \{T | T \in S  \wedge depth(T) =n\}$ for any finite $n$ %, and $k=max(depth(T_1), \ldots, depth(T_m)), T_i \in S, i \in 1..m$, 
+Given two interfaces $I$ and $J$, let $S_I$ be the set of superinterfaces of $I$,  let $S_J$ be the set of superinterfaces of $J$ and let $S =  (I \cup S_I) \cap (J \cup S_J)$.  Furthermore, we define $S_n = \{T | T \in S  \wedge depth(T) =n\}$ for any finite $n$ %, and $k=max(depth(T_1), \ldots, depth(T_m)), T_i \in S, i \in 1..m$,
 where $depth(T)$ is the number of steps in the longest inheritance path from $T$ to \code{Object}. Let $q$ be the largest number such that $S_q$ has cardinality one. The least upper bound of $I$ and $J$ is the sole element of  $S_q$.
 
 \LMHash{}
 The least upper bound of \DYNAMIC{} and any type $T$ is \DYNAMIC{}.
 The least upper bound of \VOID{} and any type $T \ne \DYNAMIC{}$ is \VOID{}.
 The least upper bound of $\bot$ and any type $T$ is $T$.
-Let $U$ be a type variable with upper bound $B$. The least upper bound of $U$ and a type $T \ne \bot$ is the least upper bound of $B$ and $T$. 
+Let $U$ be a type variable with upper bound $B$. The least upper bound of $U$ and a type $T \ne \bot$ is the least upper bound of $B$ and $T$.
 
 \LMHash{}
 The least upper bound relation is symmetric and reflexive.
@@ -7544,41 +7557,41 @@ The least upper bound relation is symmetric and reflexive.
 The least upper bound of a function type and an interface type $T$ is the least upper bound of \cd{Function} and $T$.
 Let $F$ and $G$ be function types. If $F$ and $G$ differ in their number of required parameters, then the least upper bound of $F$ and $G$ is \cd{Function}.  Otherwise:
 \begin{itemize}
-\item If 
+\item If
 
-$F= (T_1 \ldots T_r, [T_{r+1}, \ldots, T_n]) \longrightarrow T_0$, 
+$F= (T_1 \ldots T_r, [T_{r+1}, \ldots, T_n]) \longrightarrow T_0$,
 
-$G= (S_1 \ldots S_r, [S_{r+1}, \ldots, S_k]) \longrightarrow S_0$ 
+$G= (S_1 \ldots S_r, [S_{r+1}, \ldots, S_k]) \longrightarrow S_0$
 
-where $k \le n$ then the least upper bound of $F$ and $G$ is 
+where $k \le n$ then the least upper bound of $F$ and $G$ is
 
-$(L_1 \ldots L_r, [L_{r+1}, \ldots, L_k]) \longrightarrow L_0$ 
+$(L_1 \ldots L_r, [L_{r+1}, \ldots, L_k]) \longrightarrow L_0$
 
 where $L_i$ is the least upper bound of $T_i$ and $S_i, i \in 0..k$.
-\item If 
+\item If
 
 $F= (T_1 \ldots T_r, [T_{r+1}, \ldots, T_n]) \longrightarrow T_0$,
 
-$G= (S_1 \ldots S_r, \{ \ldots \}) \longrightarrow S_0$ 
+$G= (S_1 \ldots S_r, \{ \ldots \}) \longrightarrow S_0$
 
-then the least upper bound of $F$ and $G$ is 
+then the least upper bound of $F$ and $G$ is
 
-$(L_1 \ldots L_r) \longrightarrow L_0$ 
+$(L_1 \ldots L_r) \longrightarrow L_0$
 
-where $L_i$ 
+where $L_i$
 is the least upper bound of $T_i$ and $S_i, i \in 0..r$.
-\item If 
+\item If
 
-$F= (T_1 \ldots T_r, \{T_{r+1}$  $p_{r+1}, \ldots, T_f$ $p_f\}) \longrightarrow T_0$,  
+$F= (T_1 \ldots T_r, \{T_{r+1}$  $p_{r+1}, \ldots, T_f$ $p_f\}) \longrightarrow T_0$,
 
-$G= (S_1 \ldots S_r, \{ S_{r+1}$  $q_{r+1}, \ldots, S_g$ $q_g\}) \longrightarrow S_0$ 
+$G= (S_1 \ldots S_r, \{ S_{r+1}$  $q_{r+1}, \ldots, S_g$ $q_g\}) \longrightarrow S_0$
 
 then let $\{x_m, \ldots x_n\}  = \{p_{r+1}, \ldots, p_f\} \cap \{q_{r+1}, \ldots, q_g\}$ and let $X_j$ be the least upper bound of the types of $x_j$ in $F$ and $G, j \in m..n$. Then
 the least upper bound of $F$ and $G$ is
 
-$(L_1 \ldots L_r, \{ X_m$ $x_m, \ldots, X_n$ $x_n\}) \longrightarrow L_0$ 
+$(L_1 \ldots L_r, \{ X_m$ $x_m, \ldots, X_n$ $x_n\}) \longrightarrow L_0$
 
-where $L_i$ is the least upper bound of $T_i$ and $S_i, i \in 0..r$ 
+where $L_i$ is the least upper bound of $T_i$ and $S_i, i \in 0..r$
 \end{itemize}
 
 
@@ -7591,7 +7604,7 @@ where $L_i$ is the least upper bound of $T_i$ and $S_i, i \in 0..r$
 \LMHash{}
 Dart source text is represented as a sequence of Unicode code points.  This sequence is first converted into a sequence of tokens according to the lexical rules given in this specification.  At any point in the tokenization process, the longest possible token is recognized.
 
-\subsubsection{Reserved Words} 
+\subsubsection{Reserved Words}
 \LMLabel{reservedWords}
 
 \LMHash{}
@@ -7631,15 +7644,15 @@ A {\em reserved word} may not be used as an identifier; it is a compile-time err
       `/*' (MULTI\_LINE\_COMMENT $|$ \~{} `*/')* `*/'
     .
  \end{grammar}
-  
+
 \LMHash{}
-Dart supports both single-line and multi-line comments. A {\em single line comment} begins with the token \code{//}. Everything between \code{//} and the end of line must be ignored by the Dart compiler unless the comment is a documentation comment. . 
+Dart supports both single-line and multi-line comments. A {\em single line comment} begins with the token \code{//}. Everything between \code{//} and the end of line must be ignored by the Dart compiler unless the comment is a documentation comment. .
 
 \LMHash{}
-A {\em multi-line comment} begins with the token \code{/*} and ends with the token \code{*/}.  Everything between \code{/}* and \code{*}/ must be ignored by the Dart compiler unless the comment is a documentation comment. Comments may nest. 
+A {\em multi-line comment} begins with the token \code{/*} and ends with the token \code{*/}.  Everything between \code{/}* and \code{*}/ must be ignored by the Dart compiler unless the comment is a documentation comment. Comments may nest.
 
 \LMHash{}
-{\em Documentation comments} are comments that begin with the tokens  \code{///} or  \code{/**}. Documentation comments are intended to be processed by a tool that produces human readable documentation. 
+{\em Documentation comments} are comments that begin with the tokens  \code{///} or  \code{/**}. Documentation comments are intended to be processed by a tool that produces human readable documentation.
 
 
 \LMHash{}
@@ -7665,7 +7678,7 @@ Operator precedence is given implicitly by the grammar.
 
 \begin{tabular}{| r | r | r | r |}
 \hline
-Description &  Operator & Associativity & Precedence \\ 
+Description &  Operator & Associativity & Precedence \\
 \hline
 Unary postfix &  ., ?., e++, e--, e1[e2], e1() , () & None & 16 \\
 \hline
@@ -7674,7 +7687,7 @@ Unary prefix & -e, !e, \~{}e, ++e, --e & None & 15\\
 Multiplicative & *, /, \~/,  \%  & Left & 14\\
 \hline
 Additive & +, - & Left & 13\\
-\hline 
+\hline
 Shift &  $<<$, $>>$&  Left & 12\\
 \hline
 Bitwise AND & \& & Left & 11\\
@@ -7710,7 +7723,7 @@ Assignment &  =, *=, /=, +=, -= ,\&=, \^{}= etc.  &  Right &  1\\
 \LMLabel{namingConventions}
 
 \commentary{
-The following naming conventions are customary in Dart programs. 
+The following naming conventions are customary in Dart programs.
 \begin{itemize}
 \item The names of compile time constant variables never use lower case letters. If they consist of multiple words, those words are separated by underscores. Examples: PI,  I\_AM\_A\_CONSTANT.
 \item The names of functions (including getters, setters, methods and local or library functions) and non-constant variables begin with a lowercase letter. If the name consists of multiple words, each  word (except the first) begins with an uppercase letter.  No other uppercase letters are used. Examples: camlCase, dart4TheWorld