Don't allow function values in assert tests.

Don't allow function values in assert tests.

Currently you can write
  assert(() { ... });
and the function will be called and the return value used as the assert test.
This feature isn't really worth its own complexity - if you want to get the same effect, you can just write all the function:
  assert(() { ... }());
With asserts in const initializer lists, where the function call is not possible anyway, the feature went from being not very useful to being actual an complication and exception for users to remember.

R=eernst@google.com, rnystrom@google.com

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

[Lasse Reichstein Nielsen, 2017-07-10 09:38:44]

lrn@google.com changed reviewers:
+ eernst@google.com, floitsch@google.com, leafp@google.com, rnystrom@google.com

[Lasse Reichstein Nielsen, 2017-07-10 09:38:45]

Let's just do it.
We won't remove the feature from the implementations until Dart 2.0, but the
spec might as well be ready.

[eernst, 2017-07-10 10:02:25]

LGTM, mentioning a couple of typos.

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

https://codereview.chromium.org/2974763002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:6755: a statment on the form \code{\ASSERT($e$,
null);}.
Typo: `stat[e]ment`.

About white space: It used to be possible to search the spec source for
multi-word phrases using simple tools like grep. That's still possible even as
we've divided many long lines into shorter ones, but only as long as we're quite
conservative with the points of division: It's no problem to insert a newline
after end-of-sentence (after most periods), and often not a problem to split
after a comma. This particular newline is a bit more aggressive and I'd prefer
sticking to the fuzzy "don't break a meaningful unit" rule that we've been using
for a while.

https://codereview.chromium.org/2974763002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:6765: If $r$ is \TRUE{} then execution if the
\ASSERT{} statement
Typo: 'execution [o]f'

https://codereview.chromium.org/2974763002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:6773: \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.
Typo: `methods[,] one`.
Might as well add a newline at each period as usual when touching a paragraph
(then we also don't have to have an opinion about Leslie Lamport's advice of
putting double spaces after sentence-ending periods).

[Bob Nystrom, 2017-07-10 14:42:26]

lgtm

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

https://codereview.chromium.org/2974763002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:6773: \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.
"argument" -> "arguments" now that we have messages in asserts.

[Lasse Reichstein Nielsen, 2017-08-07 11:57:00]

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

https://codereview.chromium.org/2974763002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:6755: a statment on the form \code{\ASSERT($e$,
null);}.
I try to split at "meaningful" positions, which basically means at phrase or
clause boundaries.
It's not always a comma because English doesn't always use commas between
sentence parts.

https://codereview.chromium.org/2974763002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:6765: If $r$ is \TRUE{} then execution if the
\ASSERT{} statement
On 2017/07/10 10:02:25, eernst wrote:
> Typo: 'execution [o]f'

Done.

https://codereview.chromium.org/2974763002/diff/1/docs/language/dartLangSpec....
docs/language/dartLangSpec.tex:6773: \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.
On 2017/07/10 14:42:26, Bob Nystrom wrote:
> "argument" -> "arguments" now that we have messages in asserts.

Done.

[Lasse Reichstein Nielsen, 2017-08-07 13:37:38]

PTAL eernst. I upped the version to 2.0.

[eernst, 2017-08-07 14:06:39]

LGTM, noting one more typo.

About the version number: It's far too tempting for the general public (esp. the
people out there who are following Dart rather closely) to conclude that the
spec version 2.0.0 must be a specification of Dart 2.0, and we are not there
yet.

So we are probably doing ourselves a disservice if we use 2.0.0. Maybe we could
use something like `2.0.0-beta.1` such that we at least make the distance to
Dart 2.0 explicit?

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

https://codereview.chromium.org/2974763002/diff/20001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:6763: An assertion with a trailing comme is
equivalent to one with that
Typo: `comm[a]`.

[Lasse Reichstein Nielsen, 2017-08-10 13:29:07]

Description was changed from

==========
Don't allow function values in assert tests.

Currently you can write
  assert(() { ... });
and the function will be called and the return value used as the assert test.
This feature isn't really worth its own complexity – if you want to get the same
effect, you can just write all the function:
  assert(() { ... }());
With asserts in const initializer lists, where the function call is not possible
anyway, the feature went from being not very useful to being actual an
complication and exception for users to remember.
==========

to

==========
Don't allow function values in assert tests.

Currently you can write
  assert(() { ... });
and the function will be called and the return value used as the assert test.
This feature isn't really worth its own complexity - if you want to get the same
effect, you can just write all the function:
  assert(() { ... }());
With asserts in const initializer lists, where the function call is not possible
anyway, the feature went from being not very useful to being actual an
complication and exception for users to remember.
==========

[Lasse Reichstein Nielsen, 2017-08-10 13:30:11]

Description was changed from

==========
Don't allow function values in assert tests.

Currently you can write
  assert(() { ... });
and the function will be called and the return value used as the assert test.
This feature isn't really worth its own complexity - if you want to get the same
effect, you can just write all the function:
  assert(() { ... }());
With asserts in const initializer lists, where the function call is not possible
anyway, the feature went from being not very useful to being actual an
complication and exception for users to remember.
==========

to

==========
Don't allow function values in assert tests.

Currently you can write
  assert(() { ... });
and the function will be called and the return value used as the assert test.
This feature isn't really worth its own complexity - if you want to get the same
effect, you can just write all the function:
  assert(() { ... }());
With asserts in const initializer lists, where the function call is not possible
anyway, the feature went from being not very useful to being actual an
complication and exception for users to remember.

R=eernst@google.com, rnystrom@google.com

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

[Lasse Reichstein Nielsen, 2017-08-10 13:30:13]

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

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

LGTM!

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

https://codereview.chromium.org/2974763002/diff/40001/docs/language/dartLangS...
docs/language/dartLangSpec.tex:6767: An assertion on the form
\code{\ASSERT($e$))} is equivalent to an assertion on the form
\code{\ASSERT($e$, null)}.
"on" -> "of", in both places.