The actual change to the wording of `assert` that I intended in the previous CL.

The actual change to the wording of `assert` that I intended in the previous CL.

R=eernst@google.com

Committed: https://github.com/dart-lang/sdk/commit/a72f46def8899b6f1a7fc5609f3b503c5d79b16f

[Lasse Reichstein Nielsen, 2017-07-10 12:14:57]

lrn@google.com changed reviewers:
+ eernst@google.com

[eernst, 2017-07-10 13:03:59]

This on was confusing! May be a typo.

https://codereview.chromium.org/2979523002/diff/1/docs/language/dartLangSpec.tex
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/2979523002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:6777: If the class of $o$ is a subtype of
\code{Function} and assertion occurs in the initializer list of a \CONST{}
constructor,
Typo: `and [the] assertion`.

But I don't get this at all: The informal spec talks about allowing `assert` in
the initializer list of generative constructors, and they may or may not be
const. For a const constructor I'd expect that the 'condition and message
expressions in the assert must be potentially compile-time constant expressions'
which may or may not be true for that function (a static function is ok, a
function literal isn't). As a second step, we consider a specific const
constructor invocation, and that invocation will then give rise to the const
evaluation which cannot include a function call.

For a non-const instance creation expression invoking said const constructor I
would expect the function to get called (letting '$r$ be the result of invoking
$o$ with no arguments').

[Lasse Reichstein Nielsen, 2017-07-10 13:26:18]

PTAL, now with correct negation.

[eernst, 2017-07-10 14:04:54]

LGTM.

https://codereview.chromium.org/2979523002/diff/20001/docs/language/dartLangS...
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/2979523002/diff/20001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:6781: 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
execution of an assertion in a \CONST{} constructor invocation.}` ;-)

https://codereview.chromium.org/2979523002/diff/20001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:6783: Otherwise, $e$ is evaluated to an object
$m$.
It's probably easier for the reader to get this right if we prevent `Otherwise`
from covering only that sentence. We could use a semicolon: `Otherwise .. $m$;
then the execution..`.

[Lasse Reichstein Nielsen, 2017-07-11 09:51:48]

https://codereview.chromium.org/2979523002/diff/20001/docs/language/dartLangS...
File docs/language/dartLangSpec.tex (right):

https://codereview.chromium.org/2979523002/diff/20001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:6781: It is a dynamic type error if $r$ is not of
type \code{bool}.
On 2017/07/10 14:04:54, eernst wrote:
> `\commentary{Hence, it is a compile-time error if that situation arises during
> execution of an assertion in a \CONST{} constructor invocation.}` ;-)

Done.

https://codereview.chromium.org/2979523002/diff/20001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:6783: Otherwise, $e$ is evaluated to an object
$m$.
I don't feel confident using a semicolon like that, so I went with "and then".

[Lasse Reichstein Nielsen, 2017-07-11 09:52:25]

Description was changed from

==========
The actual change to the wording of `assert` that I intended in the previous CL.
==========

to

==========
The actual change to the wording of `assert` that I intended in the previous CL.

R=eernst@google.com

Committed:
https://github.com/dart-lang/sdk/commit/a72f46def8899b6f1a7fc5609f3b503c5d79b16f
==========

[Lasse Reichstein Nielsen, 2017-07-11 09:52:26]

Committed patchset #3 (id:40001) manually as
a72f46def8899b6f1a7fc5609f3b503c5d79b16f (presubmit successful).