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>
This makes it possible to run the spec parser in a way which is a bit
more like the other tools that we have (e.g., tools/test.py):
> tools/spec_parse.py tests/language/callable_test.dart
It still requires the developer to run `make parser` in
tools/spec_parser and hence does not run on a buildbot, but it's one
step forward.
Change-Id: I68ad6cea55bc02dddac21558acec33fc4bfc1981
Reviewed-on: https://dart-review.googlesource.com/9620
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The spec parser now parses all of language_2; many files are skipped,
but that is because they are multi-tests or because they contain
intentional syntax errors (negative tests).
Change-Id: I7061f0512702f3cb9631b32c79c3c1c1e2b7b0a6
Reviewed-on: https://dart-review.googlesource.com/8641
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@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>
In https://github.com/dart-lang/sdk/issues/30732 the concern was raised
that the new Function type syntax does not support metadata on
parameter specifications (i.e., on normalParameterTypes and on
namedParameterTypes).
The implication of adding support for metadata in these locations is
that `@required` can be used on function types, which is the motivation
for submitting 30732.
We have always had support on parameter declarations in function typed
parameter declarations (`void foo(@A() int f(@A() String s))`), so in
this sense there is no new semantics to worry about (Lasse: "it doesn't
mean anything anyway!").
This CL modifies the generic-function-type-alias.md informal spec to
include this kind of metadata support.
Change-Id: I4520d330458242b31c991f62c03ca2f34f9c5e54
Reviewed-on: https://dart-review.googlesource.com/5762
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@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>
The informal specifications of optional-const and optional-new used to
be incomplete, and this CL adds missing parts (transformation rules for
lists and maps, and for `assignableExpression`).
This version of the documents preserves the property that no `const` is
added without immediate syntactic justification.
The alternative (where `const` is used also in other contexts where
either `const` or `new` must be added, just because we can do that)
is not specified here, that'll be another CL. The corrections done in
this CL will be needed, anyway, so I separated the two.
R=lrn@google.com
Review-Url: https://codereview.chromium.org/3005833002 .
The informal spec of generalized void used to allow a `typeTest` on
an expression of type void. This CL removes that permission, thus
leaving only `as` as a narrow escape hatch from void, as decided at the
language team meeting on 2017-08-15.
R=lrn@google.com
Review-Url: https://codereview.chromium.org/3001063002 .
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