Also updated spec on the static and dynamic types of functions literals
and static functions along with the function objects obtained from
closurizations of them.
Introduced a separate notion of what it means to be a correct override
relation (where the old text used subtyping, which won't suffice, for
several reasons).
Introduced the notion of interfaces as a separate kind of entity that
contains method signatures (again, a new kind of entity), thus
clarifying exactly which pieces of information is available during
static analysis of member accesses, e.g., instance method invocations.
Introduced 'combined' interfaces; they are needed for `mixin`
declarations, and we will specify them soon (so it should be OK to
have them now, even though they are unused).
Change-Id: I6347df49b1aa7a81d74e25904ee75c19e8ac6930
Reviewed-on: https://dart-review.googlesource.com/c/81263
Reviewed-by: Leaf Petersen <leafp@google.com>
This is already implemented by all platforms and may be in use.
Also clean up redundant requirements for constant literals and
object expressions. There is no need to check whether `x` is constant
in order to allow `const [x]` as a potentially constant expression.
We will get a compile-time error anyway if it isn't, because that is
written explicitly for constant map literals.
Similarly for map literals and constant object expressions.
Change-Id: I425489ff3c0063fa59937978267b13ee68aa039d
Reviewed-on: https://dart-review.googlesource.com/c/81274
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Changed "compile-time warning" to "static warning"; eliminated spurious
space at the beginning of each normative paragraph; added index and
changed all `{\em ..}` containing defining occurrences of words and
phrases such that they are added to the index and marked with a
diamond in the margin (to make it easy to spot definitions).
Change-Id: I688561a24d2b9955f383d6c8db2c913353d41b4b
Reviewed-on: https://dart-review.googlesource.com/c/82501
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The analyzer enforces the rule that when a generic type alias F has
formal type parameters X1..Xm with bounds B1..Bm, if we assume that
X1..Xm are types satisfying the corresponding bounds then it must be
the case that every type which occurs in the body of F must be
regular-bounded.
In other words, the bounds on the left hand side of `=` must imply
the bounds applicable to every type on the right hand side.
---------- NEW TEXT ----------
I just discovered that it is _not_ possible to skip the check on
every super-bounded parameterized type based on a generic type
alias: It is certainly possible to have a type which is correctly
super-bounded according to the type parameter bounds on the left
hand side of `=` in the type alias declaration, and still have a
right hand side where some types are not well-bounded. Consider the
following declarations:
class B<Y1 extends Y2, Y2, Y3 extends num> {}
typedef F<X extends num> = B<num, Object, X> Function();
According to the declarations to the left of `=`, `F<Object>`
is a correct super-bounded type, because it is not
regular-bounded (`Object <\: num`), and `F<Null>` is regular-bounded
(`Null <: num`).
Also, when the declared bound of `X` is satisfied, we are
guaranteed that each type on the right hand side is regular-bounded
(if parameterized, it receives type arguments that satisfy all
the specified bounds).
But consider the result of applying `F` to `Object`:
B<num, Object, Object> Function();
That's not a type where all subterms which are types are
well-bounded:
B<num, Object, Object> is not regular-bounded because
`Object <\: num` (third type argument).
B<num, Object, Object> is not super-bounded because
B<num, Null, Null> is not regular-bounded because
`num <\: Null` (violating `Y1 extends Y2`).
So there is no way we can prove that this check can be skipped,
because we have a pretty simple counter-example!
I'm currently adjusting the text to re-introduce the check.
---------- OLD TEXT, NOT VALID ----------
This must be specified, because it justifies the _removal_ of a
requirement that we had in the feature specification
super-bounded-types.md: It was required for every application of a
generic type alias F to a list of actual type arguments <T1..Tk>
such that the resulting parameterized type F<T1..Tk> was
super-bounded that both the parameterized type F<T1..Tk> and every
type in the resulting type [T1/X1..Tk/Xk]U (where U is the body of
F and X1..Xk are its formal type parameters) be well-bounded.
But when the bounds of F imply satisfaction of the bounds of all
types that occur in the body of F, it's trivially true that all
types in the resulting type are regular-bounded for the result
of substituting Null for covariant top types and Object for
contravariant Null for every super-bounded F<T1..Tk>. I'm looking
into a proof sketch for the result that this implies that any
well-bounded generic type alias application yields a type that
contains only well-bounded types.
This would be a very welcome simplification (because it was an
inconvenient complication that we had to check both the left hand
side and the right hand side of a type alias whenever we
encountered a super-bounded type expressed via a type alias), and
I believe that it will also make the tools run faster (because they
can now skip all those checks of every type that occurs in the body
for every super-bounded usage of a type alias.
Change-Id: Icd70649ebaed41b193aeb0cb6f08d06aed0ee5bd
Reviewed-on: https://dart-review.googlesource.com/c/79743
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Also mention it in the `external const factory Symbol` constructor.
This only relevant for constant expressions that may be used as
switch case expressions or constant map keys.
See #32557.
Bug: http://dartbug.com/32557
Change-Id: Ie82799f3f0d39c21c10765338a7dfeb74a582add
Reviewed-on: https://dart-review.googlesource.com/c/81242
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Partially resolves issue #34349.
Also note that #34365 and #34319 are affected by this change.
Change-Id: I1d9023464090ff2c07f9dc062353202ddb82ba25
Reviewed-on: https://dart-review.googlesource.com/c/78121
Reviewed-by: Leaf Petersen <leafp@google.com>
This makes some parts of the specification explicit,
and rephrases it so that it is easier to recognize the separate cases.
Change-Id: Ifdbb5c11ec3b3fe80737642f230ee291a18a5841
Reviewed-on: https://dart-review.googlesource.com/c/80824
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Cf. SDK issue 34722, where the need for this clarification arose.
Change-Id: I3b1692931506410e77c59004b1ed1981a17a6f3d
Reviewed-on: https://dart-review.googlesource.com/c/78982
Reviewed-by: Leaf Petersen <leafp@google.com>
Also fix some typos.
Change-Id: Id8ed6d22c9e7c900c4062b2cbc5b68abf93d11ba
Reviewed-on: https://dart-review.googlesource.com/c/77080
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
The existing version covers generic classes only, but we should
use exactly the same rules for parameterized type aliases, which was
actually already specified in all the nested cases (e.g., `A` would mean
`A<F<dynamic>>` with the declarations `typedef F<X> = X Function();` and
`class A<X extends F<X>> {}`, but there were no rules for a plain `F`).
A rendered version corresponding to patchset 3 is available here:
https://gist.github.com/eernstg/6deffcde2cbe79f8ba499b3aac950900
Change-Id: Ic265ccc736c65361919e860b1ab7ecb947c2c066
Reviewed-on: https://dart-review.googlesource.com/c/76660
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
.. and always use a plain `constant` in normative text. Also fixed a few
LaTeX issues.
Change-Id: I5682f5c5b22120691c620144318f0670c4ba0a24
Reviewed-on: https://dart-review.googlesource.com/76980
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The existing specification was underspecifying potentially constant expressions,
effectively relying on evaluation to determine whether an expression was
potentially constant.
This change specifies potentially constant recursively using only the syntax
of the expressions.
Adds short-circuting to `?:`, `??`, `||` and `&&` expressions,
so for `String x`, the expression `x != null && x.length > 0`
is compile-time constant.
The original specification requred evaluation of the latter half
even when `x` is null. We can now avoid this because we can require that the
unused expression is a potentially constant expression without having to
check if it, or any part of it, is a compile-time constant expression.
Allows `x == null` and `x != null` as compile-time constant expression
independently of the type of `x`.
Allows `e as T` as a compile-time constant expression. Types are more
important in Dart 2, so you need a way to adjust typing in some cases,
even in compile-time constant expressions.
Change-Id: I02bf0b77013c3b3ced8cd46334db378787cc2d57
Reviewed-on: https://dart-review.googlesource.com/36220
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
We should avoid the situation where `class C extends A with M {}`
requires generation of noSuchMethod forwarders _in the superclass
`A with M`_ when neither `A` nor `M` has an implementation of
`foo`, but `A with M` has a non-trivial noSuchMethod.
If we _do_ generate those nSM forwarders, that will just obscure that
any attempt to invoke `super.foo()` in `C` should be an error.
Note that this is about generating forwarders _in the mixin application
which is the superclass_, it is not about copy-down of forwards from
the class `M` that was used to obtain the mixin in the first place.
Also note that it would be inconvenient to require all methods to be
implemented in `A with M` as used in `abstract C extends A with M {}`,
and it would also be rather funny if we were to say that `A with M` is
abstract when `C` is abstract, and concrete when `C` is concrete.
So I think the only reasonable choice is to make those superclasses
which are mixin applications abstract.
Note that dart:mirrors ought to reflect this, in a separate issue,
if it is not already the case.
Change-Id: If221b2c73b17bd55017d4d5ee4fdb8daf203e195
Reviewed-on: https://dart-review.googlesource.com/76640
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Also update type dynamic and other sections especially affected.
Change-Id: I432992b8190f13b2aea73d524fc9b17d3ef24b41
Reviewed-on: https://dart-review.googlesource.com/75340
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Also corrected some "includes" to "has" when talking about members of
an interface.
Change-Id: Ib8917c2a9f40fce82ab1e41e0e766c87065b168a
Reviewed-on: https://dart-review.googlesource.com/75880
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Also fixed many syntax related glitches.
Change-Id: I926b93a54ad28d05389a44c969fc2288933f8584
Reviewed-on: https://dart-review.googlesource.com/75580
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
---------------- NEW description (old description shown at end):
This CL is now a reorganization, problem fixing, clarifying update
to dartLangSpec.tex which was created as part of the work on the
rules for call method extraction. That is, all the call method
extraction specific elements have been _deleted_ from this CL
(they will reappear as a separate CL later). This CL is now only
performing "general clean-up work" which is needed in order to
perform many kinds of updates (including call method extraction,
but also anything else where the dynamic semantics depends on the
static analysis & desugaring).
------------------------------------------------ OLD description
Introduced rules for call method extraction.
The previous update to dartLangSpec.tex dealt with invocations, but
omitted the transformation whereby `e` becomes `e.call` when `e` has
a type which is a class with a `call` method and the context expects
a value of type `Function` or of a function type. This CL adds some
rules dealing with that and introduces a concept for the transformation
itself.
One part is missing for the initial patch set: There are no rules
specifying that call method extraction should be applied to actual
arguments. The problem is that static checking of actual arguments
to various invocations (function expression invocation, ordinary
method invocation, super invocation, etc.etc.) seems to be "delegated"
partially to section `Binding Actuals to Formals`, but that section
never defines the syntax for the function which is being invoked and
it is in general rather dynamic in nature. So I'm not quite sure
that the references to static checking at the end of that section
are located optimally.
Some adjustments may therefor be needed before we can specify this
particular feature for actual arguments.
Change-Id: Ia2ab6f16cd50e10a3c467722035f0dc4adb50587
Reviewed-on: https://dart-review.googlesource.com/51323
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The previous phrasing ("A constant expression is ... a literal string
where any interpolated expression is a compile-time constant ...") was
ambiguous: did it mean "... where at least one interpolated expression
is a compile-time constant ..." or did it mean "... where every
interpolated expression (if there are any) is a compile-time constant
..."?
Clearly the intended meaning is that all interpolated expressions are
required to be compile-time constants, otherwise we would allow
nonsense like this:
void f(int i) {
const x = 0;
const s = "$x $i"; // Ok because x is const (!)
}
Changing the word to "every" avoids the ambiguity.
Change-Id: I3a1dd38a8bc0dc9cddc7b504ea8e7de5afdf8990
Reviewed-on: https://dart-review.googlesource.com/74321
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This updates the Dart language spec to allow
```
class C with M
```
where currently the above declaration would require `extends Object`.
Change-Id: Ibb5834b264be7b2c5adb79dfa9a24ad5e1fa539a
Reviewed-on: https://dart-review.googlesource.com/73684
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
The valid return tests were misnamed and hence not run. Also remove
duplicate tests from one file, and add status to the informal proposal.
Change-Id: I20179e81a0281302056f601ee3b7a51e2aec180e
Reviewed-on: https://dart-review.googlesource.com/73562
Commit-Queue: Leaf Petersen <leafp@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
\; caused the following compilation error
! Missing $ inserted.
<inserted text>
$
l.7845 }
I have removed the backslash, and placed the semicolon between a pair
of $ to make it render like the one in the grammer-environment.
Change-Id: If57e61f61b460d159b6f14d70c9c9f343114cf70
Reviewed-on: https://dart-review.googlesource.com/71760
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
The current specification only prohibits expressions statements where the
expression *is* a map, not those that *start with* a map.
Implementations have always rejected those starting with a map.
Bug: http://dartbug.com/725
Change-Id: I805a6f82d1afdcf335aff73e74dac1f14e5a6afe
Reviewed-on: https://dart-review.googlesource.com/71247
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
In changing the proposed spec to address comments in a way that was intended to be
non-breaking, I accidentally introduced some new (unintended) restrictions. This
fixes the spec, rolls back the change in analyzer, and adjusts the language tests
appropriately.
Change-Id: I487b0eaacbfa1447d4ee909c0a56e435c2088990
Reviewed-on: https://dart-review.googlesource.com/70462
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Also remove 64-bit constraint on integer literals when compiling to JavaScript.
Effectively, all integer literals are treated the same way when compiling to JavaScript numbers.
Change-Id: Ib625457d65c40600291edbf391c82f37ad27701a
Reviewed-on: https://dart-review.googlesource.com/70144
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
We need to clarify the following case:
`dynamic foo() => print('');`,
`dynamic bar() { return print(''); }`
that is, using `return e` where `e` has type `void`, when the return
type of the enclosing function is `dynamic` (inferred or explicit).
We do not currently have any elements in the generalized-void.md
whitelist for that, so it's an error. However, invalid_returns.md
from https://dart-review.googlesource.com/c/sdk/+/60401 implies
(patchset 6: line 19-20 and 34-35) that it is allowed.
It is my impression that we agree on invalid_returns.md, and also
that it describes the current behavior (maybe not 100%?).
This indicates to me that we should, probably, add an element to
the above-mentioned whitelist to allow it.
This CL makes that change to generalized-void.md.
Change-Id: I0326081960deda907b3b4ff34bd2d60f7c9dc35b
Reviewed-on: https://dart-review.googlesource.com/64341
Reviewed-by: Erik Ernst <eernst@google.com>
The issue was raised recently that there must be generated forwarders
for some method signatures that we had not previously mentioned in
nosuchmethod-forwarders.md: Private methods with an inaccessible name,
that is, private methods declared in a different library than the
current target of nSM forwarder generation.
Given that such forwarders are semantically significant (a tear-off
performed in the library where the abstract private method declaration
is located would tear off a generated forwarder, rather than causing
an invocation of `noSuchMethod`), we need to specify this.
This CL adds such a specification to nosuchmethod-forwarders.md.
This CL addresses SDK issue #33725, and SDK issue #33727 is related
being concerned with the implementation in the common front
end.
Change-Id: Iedbcdd8b4c8df95c6038022f72b3211ec1b76649
Reviewed-on: https://dart-review.googlesource.com/64380
Reviewed-by: Erik Ernst <eernst@google.com>
This mostly documents and regularizes existing (post bug fix) semantics,
with a small additional restriction on returning `void` from an async
function.
Change-Id: Ic1a302aeb666fa73ca2b7e23072394490bb4fe76
Reviewed-on: https://dart-review.googlesource.com/60401
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
This CL adds a new feature specification for 'generic function
instantiation' (aka partial specialization, type-curried invocation,
etc.), which amounts to implicitly obtaining a non-generic function
from a denotation of a generic function when the typing requires the
latter.
This feature spec relies on type inference, but as a black box (so
it can hardly be incompatible with any current or future version of
type inference in Dart).
Note that it is a restricted version of generic function
instantiation which is specified here, it only supports global and
static functions and instance methods; function literals and first
class function values are not supported.
I just learned from Vijay (Mar 23, 3pm CET) that first class functions
_do_ support generic function instantiation in some existing
implementations. So maybe there is no problem supporting them, and
we should just eliminate that restriction?
Here is a rendered version of the document, refreshed to match patch
set 19: https://gist.github.com/eernstg/bf816d3495e9b87ab6eb958ba707d016
Change-Id: Ie1fd601d3e359bfb5f4616f8ec68a110f42e01b7
Reviewed-on: https://dart-review.googlesource.com/47043
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The current specification seems to allow (or even mandate) that a
redirecting constructor (factory or generative) must be considered as a
syntactic shorthand for an invocation of the redirection target, with
no checks applied statically or dynamically according to the
declarations in the redirected constructor. So the following would be
OK:
class A {
A(num n) { print(n); }
A.foo(int i): this(i);
}
main() => new A.foo(3.0);
This CL changes dartLangSpec.tex to mandate all the checks (static
and dynamic) for the declaration of the redirecting constructor as
well as each one of the redirection targets.
Note that the analyzer already rejects the above program, which
lessens the disruption and the implementation burden, but compilers
would presumably need to have the dynamic checks implemented.
Underlying issues: https://github.com/dart-lang/sdk/issues/31590,
https://github.com/dart-lang/sdk/issues/32049,
https://github.com/dart-lang/sdk/issues/32511.
Change-Id: Icc15da6b817e4e678cdfc8829a1e06458756eb4b
Reviewed-on: https://dart-review.googlesource.com/28140
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
We did not previously prevent `class C implements FutureOr<int> ..` and
similar declarations. However, it offers only very little value to
allow this, and possibly creates some complications. This CL makes all
these subtype relationships a compile-time error.
The wording of the constraint on `\WITH{} clause` was also adjusted to
remove some potential interpretations which are unintended (like
preventing `with List<dynamic>`, which should be OK).
Change-Id: I626c2767befa7a3cb3092b0ba5cb463e9456d431
Reviewed-on: https://dart-review.googlesource.com/63583
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
We noted in issue https://github.com/dart-lang/sdk/issues/33709 that
the language specification prevents usage of `Null` as the bound
of a type variable, because that makes the bound a subtype of
the type variable itself (which is otherwise a symptom of having
a cyclic declaration like `X extends X`).
This CL adjusts the wording such that it will be possible to use
`Null` (or whatever the denoteable bottom type is called) as a
bound.
Change-Id: I46a5ce6055f3af322a6b93ac38ca2829ce23a26c
Reviewed-on: https://dart-review.googlesource.com/63420
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Change-Id: I2760f333c96470dd3a58dc8d9c389a5c1242a83f
Reviewed-on: https://dart-review.googlesource.com/63384
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Change-Id: I3c6fe9d27aad387a55f9a003d94faa6a9a72f227
Reviewed-on: https://dart-review.googlesource.com/44741
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Don't use $e$ for two different things, and specify static type.
Fixes#19517.
Bug: http://dartbug.com/19517
Change-Id: Ieb30fc05dc305f25526b05b2005a1a81a88e2009
Reviewed-on: https://dart-review.googlesource.com/61881
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
The text still uses "with the same URI" as a proxy for "being the
same library" (as it always did). We may wish to change that to
something which will catch the case where different URIs denote the
same library.
Note that this is concerned with the specification,
the feature has been implemented in
08de1b30aa.
Closes-bug: #33225
Change-Id: I678379e98a98c2a021ce2e02c8d942c074ff583c
Reviewed-on: https://dart-review.googlesource.com/60660
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Also update the `int` class documentation.
Change-Id: I2de6c62aa9642c18134effa8187a12902d5f2259
Reviewed-on: https://dart-review.googlesource.com/58204
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Argh, the `git cl upload` was waiting for an `ENTER` press when I
landed CL 56487. This CL just deletes that TODO comment.
Change-Id: I58843d8ae984363ca1b8bacd2f735efa50c9b666
Reviewed-on: https://dart-review.googlesource.com/60249
Reviewed-by: Erik Ernst <eernst@google.com>
Change-Id: I4a8fc32071804c5edd0f7aab905ea4402df4414d
Reviewed-on: https://dart-review.googlesource.com/60102
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
TBR: This CL only adds a missing changelog entry for the commit
08c893d55b.
Change-Id: I4963dbebc090e95b26ce043586cfa2db0df95f3c
Reviewed-on: https://dart-review.googlesource.com/57502
Reviewed-by: Erik Ernst <eernst@google.com>
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 adds an example to super-bounded-types.md in order to motivate
the definition of what it means for a parameterized type based on a
type alias to be super-bounded. The definition says that we must check
the actual type arguments relative to the formal type parameter
list of the given `typedef` as well as the right hand side, replacing
the formals by the given actual type arguments. The example shows that
the right hand side can be ill-bounded even though the check that we
apply based on the formal type parameter bounds (that is, the check
that we apply to class types) succeeds.
A rendered version of super-bounded-types.md corresponding to patchset
6 is available here:
https://gist.github.com/eernstg/fc12eeb23064a2578a936b443461dde4.
Change-Id: I33dc6ced592f53160bc6f933558bfface46cd329
Reviewed-on: https://dart-review.googlesource.com/56668
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: Leaf Petersen <leafp@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>
Sergey pointed out a couple of name clashes, and I renamed some indices
in order to avoid them. At the same time, I fixed a couple of typos
and adjusted the whitespace to be more similar to other *.md files.
Finally, I adjusted the wording involving 'algorithmic' and 'syntax
directed' in order to make it explicit that they stand for the same
thing.
Change-Id: Ic03b907f4bdc722d9ba218d38077addf9cc4a777
Reviewed-on: https://dart-review.googlesource.com/50981
Reviewed-by: Leaf Petersen <leafp@google.com>
The "special case" text just says that the return type of `~/` on `int` is `int`, which is also its declared type, so the text isn't necessary.
Bug: http://dartbug/com/15650
Change-Id: Iba7fcc621e27dcba24dfdede2a0960f2f5ecd2f9
Reviewed-on: https://dart-review.googlesource.com/48144
Reviewed-by: Erik Ernst <eernst@google.com>
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
In response to the discussions in SDK issue 32414 about the typing of
members of `Object` when the receiver type is `dynamic`.
A rendered version of this document is available at
https://gist.github.com/eernstg/fc0094b0230ea18b9507092e50dab537
(uploaded as of patchset 6).
Change-Id: I3a74ecd5e7c9c9c05fadda5b1fa0d644561796e9
Reviewed-on: https://dart-review.googlesource.com/46247
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
As an example of a void-to-void data flow, consider `void x = foo();`,
where `foo` has return type `void`. In general, a void-to-void data
flow is a computation which is trivial (we may select one of two
branches in a conditional expression and otherwise only pass the value
on without any computation) where the expression being evaluated has
type void, and the target that receives the value is also of type
void.
This CL makes adjustments to generalized-void.md such that void-to-void
data flows are allowed.
Change-Id: Ia1722cd399c77c57cc5c61e9c10b7a84a18fe107
Reviewed-on: https://dart-review.googlesource.com/38060
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
It turns out that the special case for FutureOr<void> that I added in
https://dart-review.googlesource.com/c/sdk/+/35920 was misunderstood,
nobody really wanted it.
This CL removes all references to `FutureOr` in generalized-void.md,
which removes that special case and also the concept of types that are
"void equivalent" (because such types are not used any more).
The message here is that we are now more consistent in our protection
of developers against accidentally discarding a value which is
meaningful (just like `void foo() { return 42; }`), because they've
forgotten that the return type is `void`.
Change-Id: Ia4e6e00b2d33ff434923de7eb78d000cd7cc1c3e
Reviewed-on: https://dart-review.googlesource.com/41822
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Change-Id: Ic6eeffd2e3d348f636af5ab4644cc60b87e85506
Reviewed-on: https://dart-review.googlesource.com/29060
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
A similar rule applies to asynchronous for-in loops.
Change-Id: I88ba234c27a38167eaac0350d269e88894a0fe9e
Reviewed-on: https://dart-review.googlesource.com/35920
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The language team several times agreed to make it an error when a
non-void expression `e` is used in `return e;` in the body of a
function whose return type is `void`.
When `void` is changed from a near-bottom type to a top type, the
wording in the language specification (dartLangSpec.tex) does _not_
ensure that this is an error, because all types are assignable to
`void`, so we need a specific rule saying that it is an error.
This CL adds such a rule to the feature spec for generalized void.
It also adds a rule that makes it an error to have return type `void`
in a function marked `async*` or `sync*`, based on the reasoning
that they "are returning a Future/Stream/Iterable semantically",
and it would now be an error if they did that explicitly.
Change-Id: I22fed9e9fc6097bb50100a151b964045e41ef173
Reviewed-on: https://dart-review.googlesource.com/35680
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Description which is relevant as of January 2018:
The more aggressive approach where `const` is inserted whenever
possible (for instance creation expressions) and whenever required
(for composite literals), and `new` is inserted otherwise, is now
the agreed policy. This means that the remaining discussion is on
the specification of this policy, not the policy itself. This has
been true approximately since Dec 1st, 2017.
Here is a brief overview of the feature which is specified in the
document added by this CL:
The introduction of 'implicit creation' adjusts the grammar such
that instance creation expressions (such as `new C()`) can always
omit the keyword (`new` or `const`). The semantics is that these
expressions will still invoke the same constructor (which may
produce a fresh instance in case of a generative constructor, and
some object that may or may not be new in case of a factory),
as if `new` or `const` had been added implicitly. The choice of
whether to add `new` or `const` is made according to the policy
described above.
----------------------------------------------------------------------
Original description, FYI:
Copy of Rietveld 3012703002: magic optional const
Adjusted informal spec optional-new to insert `const` whenever possible
The current version of optional-new.md specifies that `const` should be
inserted into certain syntactic phrases (when specific identifiers
satisfy some constraints), but only when these phrases occur in a const
context.
This CL changes that approach and specifies that `const` should also be
inserted outside const contexts, if the resulting expression is a
correct constant expression.
We haven't yet decided on whether we want the current (predictable)
model or we want the more "magic" one specified in this CL; this CL
is intended to be landed if we choose the latter, and discarded if we
choose the former.
Change-Id: I602e7eaf3d4c7904277af45c6f62089c77bd5117
Reviewed-on: https://dart-review.googlesource.com/3160
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
The covariant parameter related feature specs were written to specify
that overriding admits a type annotation `T` on a formal parameter as
long as `T <: S` or `S <: T` for every type annotation `S` on a
corresponding formal parameter in an overridden declaration (directly
or indirectly).
This CL changes the rules such that a covariant-from-class parameter
must satisfy the standard constraints (contravariance) instead, which
is needed in order to ensure that an important optimization (on self-
sends) is valid.
This makes the spec follow the actual implementation, i.e., the change
will not break any existing software.
Change-Id: Ic871cc16c09220a385d68d9ec32c7a06683db87b
Reviewed-on: https://dart-review.googlesource.com/37664
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
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>
