Add assert-in-initializer-list to formal specification.

docs/language/dartLangSpec.tex

 \documentclass{article}
 \usepackage{epsfig}
 \usepackage{color}
 \usepackage{dart}
 \usepackage{bnf}
 \usepackage{hyperref}
 \usepackage{lmodern}
 \usepackage[T1]{fontenc}
 \newcommand{\code}[1]{{\sf #1}}
 \title{Dart Programming Language  Specification  \\
@@ skipping 11 matching lines @@
 % 1.15
 % - Change how language specification describes control flow.
 % - Object initialization now specifies initialization order correctly.
 % - Specifies that leaving an await-for loop must wait for the subscription
 %   to be canceled.
 % - An await-for loop only pauses the subscription if it does something async.
 % - Assert statements allows a "message" operand and a trailing comma.
 % - The Null type is now considered a subtype of all types in most cases.
 % - Specify what NEWLINE means in multiline strings.
 % - Specified the FutureOf type.
+% - Asserts can occur in initializer lists.
 %
 % 1.14
 % - The call "C()" where "C" is a class name, is a now compile-time error.
 % - Changed description of rewrites that depended on a function literal.
 %   In many cases, the rewrite wasn't safe for asynchronous code.
 % - Removed generalized tear-offs.
 % - Allow "rethrow" to also end a switch case. Allow braces around switch cases.
 % - Allow using '=' as default-value separator for named parameters.
 % - Make it a compile-time error if a library includes the same part twice.
 % - Now more specific about the return types of sync*/async/async* functions
@@ skipping 1355 matching lines @@
 \LMHash{}
 An initializer list begins with a colon, and consists of a comma-separated list of individual {\em initializers}. There are two kinds of initializers.
 \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.
 \end{itemize}
 
 \begin{grammar}
 {\bf initializers:}
-      `{\escapegrammar :}' superCallOrFieldInitializer (`,' superCallOrFieldInitializer)*
+      `{\escapegrammar :}' initializerListEntry (`,' initializerListEntry)*
     .
 
 
-{\bf superCallOrFieldInitializer:}\SUPER{} arguments;
+{\bf initializerListEntry:}\SUPER{} arguments;
       \SUPER{} `{\escapegrammar .}' identifier arguments;
-     fieldInitializer
+     fieldInitializer;
+     assertion
     .
 
    {\bf  fieldInitializer:}
       (\THIS{} `{\escapegrammar .}')? identifier `=' conditionalExpression cascadeSection*
     .
 
 \end{grammar}
 
 \LMHash{}
 Let $k$ be a generative constructor.
@@ skipping 89 matching lines @@
 
 \LMHash{}
 First, the expression $e$ is evaluated to an object $o$.
 Then, the instance variable $v$ of $i$ is bound to $o$.
 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 instance variable $v$.
 
 \LMHash{}
 An initializer of the form \code{$v$ = $e$} is equivalent to an initializer of the form \code{\THIS{}.$v$ = $e$}.
 
 \LMHash{}
+Execution of an initializer that is an assertion proceeds by executing the assertion (\ref{assert}).
+
+\LMHash{}
 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})$
 
 (respectively  \SUPER{}$.id(a_1, \ldots, a_n, x_{n+1}: a_{n+1}, \ldots, x_{n+k}: a_{n+k})$
 
 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.
@@ skipping 1083 matching lines @@
 \item An expression of the form \code{$e_1 ?? e_2$} where $e_1$ and $e_2$ are constant expressions.
 \item An expression of the form \code{$e$.length} where $e$ is a constant expression that evaluates to a string value.
 \end{itemize}
 
 % null in all the expressions
 
 % 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 throw an exception.
+It is a compile-time error if an assertion is part of a compile-time constant constructor invocation and the assertion would throw an exception.
 
 % so, checked mode? analyzers? editor/development compilers?
 \commentary{
 Note that there is no requirement that every constant expression evaluate correctly. Only when a constant expression is required (e.g., to initialize a constant variable, or as a default value of a formal parameter, or as metadata) do we insist that a constant expression actually be evaluated successfully at compile time.
 
 The above is not dependent on program control-flow. The mere presence of a required compile time constant whose evaluation would fail within a program is an error.  This also holds recursively: since compound constants are composed out of constants, if any subpart of a constant would throw an exception when evaluated, that is an error.
 
 On the other hand, since implementations are free to compile code late, some compile-time errors may manifest quite late.
 }
 
@@ skipping 4096 matching lines @@
 
 
 \subsection{ Assert}
 \LMLabel{assert}
 
 \LMHash{}
 An {\em assert statement} is used to disrupt normal execution if a given boolean condition does not hold.
 
 \begin{grammar}
 {\bf assertStatement:}
-   assert `(' expression ( `,' expression )? `,'? `)' `{\escapegrammar ;}'
-      .
+    assertion `{\escapegrammar ;}'
+    .
+{\bf assertion:}
+    \ASSERT{} `(' expression ( `,' expression )? `,'? `)'
+    .
 \end{grammar}
 
 \LMHash{}
 The grammar allows a trailing comma before the closing parenthesis,
 similarly to an argument list. That comma, if present, has no effect.
-An assert statement with a trailing comme is equivalent to one with that
+An assertion with a trailing comme is equivalent to one with that
 comma removed.
 
 \LMHash{}
-An assert statement on the form \code{\ASSERT($e$);)} is equivalent to a statment on the form \code{\ASSERT($e$, null);}.
+An assertion on the form \code{\ASSERT($e$))} is equivalent to an assertion
+on the form \code{\ASSERT($e$, null)}.
 
 \LMHash{}
-The assert statement has no effect in production mode. In checked mode, execution of an assert statement \code{\ASSERT{}($c$, $e$);} proceeds as follows:
+Execution of an assert statement executes the assertion as described below
+and completes in the same way as the assertion.
 
 \LMHash{}
-The expression $c$ 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$.
+In production mode the assertion has no effect
+and its execution immediately completes normally (\ref{completion}).
+In checked mode,
+execution of an assertion \code{\ASSERT{}($c$, $e$)} proceeds as follows:
+
+\LMHash{}
+The expression $c$ is evaluated to an object $o$.
+If the class of $o$ is not a subtype of \code{Function} then
+let $r$ be $o$.
+Otherwise,
+if the assertion occurs in the initializer list of a \CONST{} constructor,
+then we say that the assertion failed,
+otherwise let $r$ be the result of invoking $o$ with no arguments.
 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 completes normally (\ref{completion}).
 If the assertion failed, $e$ is evaluated to an object $m$.
 Then the execution of the assert statement throws (\ref{completion}) an \code{AssertionError} containing $m$ and with a stack trace corresponding to the current execution state at the \ASSERT{} statement.
 
 \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}.
+If the assertion occurs in a \CONST{} constructor initializer list, it is a static type warning if the type of $e$ may not be assigned to \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
 %\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.
@@ skipping 1434 matching lines @@
 
 The invariant that each normative paragraph is associated with a line
 containing the text \LMHash{} should be maintained.  Extra occurrences
 of \LMHash{} can be added if needed, e.g., in order to make
 individual \item{}s in itemized lists addressable.  Each \LM.. command
 must occur on a separate line.  \LMHash{} must occur immediately
 before the associated paragraph, and \LMLabel must occur immediately
 after the associated \section{}, \subsection{} etc.
 
 ----------------------------------------------------------------------