Don't allow function values in assert tests.

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  \\
+\title{Dart Programming Language Specification  \\
 {5th edition draft}\\
-{\large Version 1.15.0}}
+{\large Version 2.0.0-dev}}
 
 % For information about Location Markers (and in particular the
 % commands \LMHash and \LMLabel), see the long comment at the
 % end of this file.
 
 % CHANGES
 % =======
 % Significant changes to the specification.
 %
+% 2.0
+% - Don't allow functions as assert test values.
+%
 % 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.
@@ skipping 6718 matching lines @@
     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 assertion with a trailing comme is equivalent to one with that
+An assertion with a trailing comma is equivalent to one with that
 comma removed.
 
 \LMHash{}
-An assertion on the form \code{\ASSERT($e$))} is equivalent to an assertion
-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)}.

[Bob Nystrom, 2017/08/14 21:22:43]

"on" -> "of", in both places.

 
 \LMHash{}
 Execution of an assert statement executes the assertion as described below
 and completes in the same way as the assertion.
 
 \LMHash{}
-In production mode the assertion has no effect
+In production mode an 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 a subtype of \code{Function}
-and the assertion does not occur in the initializer list of a \CONST{} constructor,
-then let $r$ be the result of invoking $o$ with no arguments.
-Otherwise let $r$ be $o$.
+The expression $c$ is evaluated to an object $r$.
 It is a dynamic type error if $r$ is not of type \code{bool}.
 \commentary{Hence it is a compile-time error if that situation arises during evaluation of an assertion in a \CONST{} constructor invocation.}
-If $r$ is \TRUE{}, execution of the assert statement completes normally (\ref{completion}).
+If $r$ is \TRUE{} then execution of the assert statement completes normally (\ref{completion}).
 Otherwise, $e$ is evaluated to an object $m$
-and 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.
+and 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 assertion.
 
 \LMHash{}
-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}.
+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.
+\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 arguments 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.
 %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.,}
@@ skipping 1432 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.
 
 ----------------------------------------------------------------------