The Dart 1 specification of 'generic method syntax' had no status
indicator, it is now marked as 'background material' because generic
methods (in full) have been integrated into the language specification.
Several other changes of a similar nature.
Implication: It should now be possible for readers of these documents
to trust their status indication. As we go, we will need to update them
again, especially when something is integrated into the language
specification.
Do we want to migrate background material to another directory? Do we
want to rename the directory `informal` to `feature` or somesuch?
Change-Id: Ia3851bdbe7b5a46d71848c376906f95feb4db349
Reviewed-on: https://dart-review.googlesource.com/34663
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This CL changes said document to drop support for requested generation
of forwarder in case of a conflict. Developers must then write a
disambiguating method implementation themselves.
Note that this is what we already agreed during discussions about
this feature, but I noted that it hadn't yet been written into the
document.
Also changes the status to 'under implementation'.
Change-Id: I31b3dd8d65438484824225ad7067d36462d26aa7
Reviewed-on: https://dart-review.googlesource.com/22421
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
The discussion about SDK issue 31305 showed that the definition of
covariant/contravariant/invariant occurrences need to be given
somewhere, and also that covariant-from-class.md is a reasonable place
to put it.
This CL adds those definitions there, based on Leaf's proposal in the
above-mentioned issue, and adjusts the definition of what it means to
be a covariant parameter such that the case where the relevant type
parameter occurs in the bound of a formal type parameter in a function
type is taken into account.
(It also reformats the document to stay within 80 columns and follow
the style of newer informal specs more closely, but that should be
easy to skip over because Gerrit colors white space changes
differently from "real" changes).
Change-Id: I0b0a688c616d0bb56755ceea08e1792abfa7936d
Reviewed-on: https://dart-review.googlesource.com/23422
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Eliminated the imprecise notion of an immediate subexpression.
Included missing rule for transformation of composite literals
(lists and maps). Some smaller fixes according to feedback by
mail.
Change-Id: I03e58dd24b370b797cda084bd064c6f0db22f8fb
Reviewed-on: https://dart-review.googlesource.com/4383
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Bob Nystrom <rnystrom@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>
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 .
Erik Ernst