As of patchset 5: The ruleset concerning class member conflicts
(apart from simple name clashes) has now been simplified
considerably, and it's expressed in one location, in a new section
(the locations where we previously had such rules are now
`\commentary{}` with a reference to the new section).
The old rules and the new simplified rules specify the same set
of conflicts (in that sense, patchset 4 == patchset 5).
The old description below gives details about what was changed
from the start of this CL until patchset 4.
------------------------------- OLD description:
Added conflict for constructor and setter with "the same name".
Discussed the inconsistent approach to conflicts between named
constructors and instance members with Lasse; we agreed that it
is confusing if we allow the constructor `C.n` to coexist with the
instance method/getter `n` and instance setter `n=`, except that
they must be inherited rather than declared in the enclosing class
`C`, so I adjusted the wording such that only _static_ members
conflict with named constructors.
One more reason why there is no conflict between `C.n` and an instance
member named `n` or `n=` is that the latter can _never_ be denoted
by `C.n` (but static members can be denoted by `C.n`, also in `C`).
Change-Id: I012e772ae6473fddd8f9944553d69e6a6ceeb2f9
Reviewed-on: https://dart-review.googlesource.com/56800
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This CL changes dartLangSpec.tex to say that 'closurization' takes
place (rather than just saying that it's a 'function') when a
global/local/static function is torn off, just like it always did
for instance methods. Also, it standardizes on using the phrase
'function object' to denote the run-time entity obtained from such
a closurization.
This addresses the non-generic parts of the request in #31665.
Change-Id: I6967a74df178fbb26af0f572b0471219d3169e4f
Reviewed-on: https://dart-review.googlesource.com/46860
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Remove places where you were technically allowed to add spaces between
individual characters, but no implementation actually allowed it.
Change-Id: I0a13c9e3995b897135cd578a7d8c114f7746f991
Reviewed-on: https://dart-review.googlesource.com/34640
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
In dartLangSpec.tex there used to be many white space anomalies, e.g.,
double spaces between words with no apparent justification
or multiple empty lines
or lines starting with indentation that wasn't justified by any
consistent rule that I could spot.
This CL fixes that.
It also adjusts the grammar rules to be formatted in a systematic way
which will be helpful for an update to use something else than
bnf.sty (that we can't distribute due to license problems).
In particular, when a right hand side is too long for one line it used
to flow into the next line just like text (so non-terminals would have
`-` inserted at locations where a natural language algorithm thought
the "word" could be split in two, and the indentation on the next line
was nonsensical). So now it uses `\gnewline{}` ("grammar newline") to
switch to a new line and indent somewhat. It also uses `\gcomma{}` to
produce a quoted comma (which otherwise looks funny, because the `,'
becomes more like `, ' because the comma has a sort of built-in space
after it).
The command `\cd{...}` is gone and `\code{...}` is used everywhere.
Every sentence is now terminated by a newline. This doesn't mean that
every line is <80 chars, but it is at least much more readable (in
an editor whose window is really big), and it's consistent with the
more radical changes that we have made whenever we have made bigger
changes to a paragraph.
Finally, all comments on interface injection and all comments on
spread and rest arguments have been deleted. These comments contained
considerations about said features, but they did not contribute to
the discussions that we have had about the same or similar topics
(in particular because the comments relied on assumptions that do
not hold any more).
So it's a big diff, but a huge portion of it is white space fixes,
and the rest is very systematic. So it should be bearable, and we
would surely need to do the same things over time, otherwise.
Change-Id: Ia5922c22cb496792d394e76ce8c7bca7df1b4cc8
Reviewed-on: https://dart-review.googlesource.com/25000
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Update `return e;` in `async` function to do an implicit await if the value is async.
(We can make it an explicit await that also waits if it's not a future).
Make it explicit that we don't allow two different instantiations of the same interfaces.
Change-Id: I66de9ec55c1d55523d91e6d2bbebcb7d02ef301f
Reviewed-on: https://dart-review.googlesource.com/23663
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
The spec would sometimes use the reserved word (boldface) null, which
is an expression, when it really meant the value of that expression.
Since that value has a defined name, "the null object", use it
correctly and consistently.
The spec would also use the phrase "the null value", which presumably
just meant the null object. Replace occurrences of this phrase with
"the null object".
Bug:
Change-Id: Ibadeb97fe3bec67cd77d6a8d6c57e922cea265d3
Reviewed-on: https://dart-review.googlesource.com/22461
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
The spec was not self-consistent with respect to the usage of various forms
of 'run time' and 'compile time', even when using them as formally defined
terms (e.g., compile-time error).
Consistently follow the conventions: that 'run-time' and 'compile-time' are
adjectives and not nouns; that 'run time' and 'compile time' are noun
phrases containing an adjective and not adjectives themselves; and that
'runtime' and 'compiletime' are nonsense or at least jargon and are avoided.
Fixes https://github.com/dart-lang/sdk/issues/25883
Bug:
Change-Id: I0a9eb524bb43ed6c3a74e6ef038184bcbe979966
Reviewed-on: https://dart-review.googlesource.com/21345
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Kevin Millikin <kmillikin@google.com>
This CL updates section 'Function Expression Invocation' in
dartLangSpec.tex to specify that it is a static warning to use the
value of an expression of type `Object` as a function.
We still _allow_ using a `Function` and a `dynamic` value as a function
by means of `assignable`, because these two things together are rather
concise, and they say the right thing.
It is a bit convoluted, though, because `Object` seems to be OK
according to the first sentence, and then it's ambushed by the second
sentence. Proposals for a more elegant wording welcome! ;-)
Change-Id: I997399b9e10da339df359e9c6a339249ab97acf9
Reviewed-on: https://dart-review.googlesource.com/11480
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
During migration of lib/mirrors/initializing_formals_test.dart to lib_2
it became apparent that strong mode makes it an error to have different
type annotations on an initializing formal and the corresponding field.
The language team discussed this and decided that we will take a middle
way: These type annotations can differ, but the initializing formal
must have a subtype.
This CL adjusts the spec to say that. In line with the rest of the
spec it is still a static warning (we will migrate all the static
warnings to errors as a separate step).
Change-Id: I66656c2933b7f86b78f0b06eadbf5edc0f58a3c6
Reviewed-on: https://dart-review.googlesource.com/7264
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Currently the spec says that namedArguments of, say, a setter Invocation must
return the `const{}` map. That's badly typed for Dart 2(it should at least
be `const <Symbol,Object>{}`) and unnecessarily specific.
This change just requires the object to be empty and unmodifiable.
Also remove the spec handling invalidly overridden noSuchMethod.
That's not longer possible in Dart 2.
Change-Id: I3a983a44dd5939e42c85a53e9769f5961e03b986
Reviewed-on: https://dart-review.googlesource.com/6462
Reviewed-by: Erik Ernst <eernst@google.com>
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
Review-Url: https://codereview.chromium.org/2974763002 .
Erik Ernst