languages/dart-sdk
languages/dart-sdk
1
0
Fork 0
mirror of https://github.com/dart-lang/sdk synced 2024-10-01 17:02:10 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update the language changes in the CHANGELOG for 2.15.

Browse source 
- Remove all references to "beta preview".
- Consolidate the text about requiring a >=2.15 language version into a
  single paragraph for all language features.
- Consistent hyphenation of "tear-off" (the noun) and "tear off" (the
  verb).
- Remove the unnecessarily-specific examples of function equality.
- Couple of other minor formatting tweaks.

Change-Id: Ic8cd601916ba53056f3da34a9cfc2b8f938d0f36
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218986
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Michael Thomsen <mit@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
This commit is contained in:
Robert Nystrom 2021-11-04 19:17:54 +00:00 committed by commit-bot@chromium.org
parent 96d40d1caa
commit 5331d12f3f
1 changed files with 38 additions and 140 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

178
CHANGELOG.md
View file

@ -2,14 +2,19 @@
### Language
- **[Constructor tearoffs][]**: **BETA PREVIEW**
The following new features are new in the Dart 2.15 [language version][]. To use
them, you must set the lower bound on the SDK constraint for your package to
2.15 or greater. (If using a beta preview release, use an SDK constraint of
`>=2.15.0-0`):
Previous Dart versions allowed a method on an instance to be passed as a
closure, and similarly for static methods. This is commonly referred to as
"closurizing" or "tearing off" a method. Constructors were not previously
eligible for closurization, forcing users to explicitly write wrapper
functions when using constructors as first class functions, as in the calls to
`List.map` in the following example:
[language version]: https://dart.dev/guides/language/evolution
- **[Constructor tear-offs][]**: Previous Dart versions allowed a method on an
instance to be passed as a closure, and similarly for static methods. This is
commonly referred to as "closurizing" or "tearing off" a method. Constructors
were not previously eligible for closurization, forcing users to explicitly
write wrapper functions when using constructors as first class functions, as
in the calls to `map()` in the following example:
```dart
class A {
@ -55,10 +60,10 @@
```
Constructors for generic classes may be torn off as generic functions, or
instantiated at the tear off site. So in the following code, the tear off
instantiated at the tear-off site. So in the following code, the tear-off
`G.new` used to initialize the variable `f` produces a generic function which
may be used to produce an instance of `G<T>` for any type `T` provided when
`f` is called. The tear off `G<String>.new` used to initialize the variable
`f` is called. The tear-off `G<String>.new` used to initialize the variable
`g` on the other hand produces a non-generic function which may only be used
to produce instances of type `G<String>`.
@ -76,27 +81,14 @@
}
```
The new constructor tearoff feature is currently in **BETA PREVIEW**. The
feature is enabled in beta releases only, and is still subject to breaking
changes. It is not fully supported by all tools and there may be known issues
with the tool support. Feedback on the feature is welcome, but it is not
recommended that production code use the feature until it has been released in
a stable version.
[constructor tear-offs]: https://github.com/dart-lang/language/blob/master/accepted/future-releases/constructor-tearoffs/feature-specification.md
The new constructor tearoff feature is only available as part of the 2.15
[language version](https://dart.dev/guides/language/evolution). To use this
feature, you must set the lower bound on the sdk constraint for your package
to 2.15 or greater (if using a beta preview release, an sdk constraint of
`>=2.15.0-0` must be used).
- **[Generic type literals][Explicit instantiation]**: **BETA PREVIEW**
Previous Dart versions allowed class names to be used as type literals. So
for example,`int` may be used as an expression, producing a value of type
`Type`. Generic classes (e.g. `List`) could be referred to by name as an
expression, but no type arguments could be provided and so only the `dynamic`
instantiation could be produced directly as an expression without using
indirect methods:
- **[Generic type literals][explicit instantiation]**: Previous Dart versions
allowed class names to be used as type literals. So for example,`int` may be
used as an expression, producing a value of type `Type`. Generic classes (e.g.
`List`) could be referred to by name as an expression, but no type arguments
could be provided and so only the `dynamic` instantiation could be produced
directly as an expression without using indirect methods:
```dart
// Workaround to capture generic type literals.
@ -121,23 +113,15 @@
}
```
The new generic type literal feature is currently in **BETA PREVIEW**. The
feature is enabled in beta releases only, and is still subject to breaking
changes. It is not fully supported by all tools and there may be known issues
with the tool support. Feedback on the feature is welcome, but it is not
recommended that production code use the feature until it has been released in
a stable version.
Generic type literals are only available as part of the 2.15 [language
version](https://dart.dev/guides/language/evolution). To use this feature, you
must set the lower bound on the sdk constraint for your package to 2.15 or
greater (if using a beta preview release, an sdk constraint of
must set the lower bound on the SDK constraint for your package to 2.15 or
greater (if using a beta preview release, an SDK constraint of
`>=2.15.0-0` must be used).
- **[Explicit generic method instantiations][Explicit instantiation]**: **BETA PREVIEW**
Previous Dart versions allowed generic methods to be implicitly specialized
(or "instantiated") to non-generic versions when assigned to a location with a
- **[Explicit generic method instantiations][explicit instantiation]**: Previous
Dart versions allowed generic methods to be implicitly specialized (or
"instantiated") to non-generic versions when assigned to a location with a
compatible monomorphic type. Example:
```dart
@ -177,30 +161,12 @@
}
```
The new generic method instantation feature is currently in **BETA PREVIEW**.
The feature is enabled in beta releases only, and is still subject to breaking
changes. It is not fully supported by all tools and there may be known issues
with the tool support. Feedback on the feature is welcome, but it is not
recommended that production code use the feature until it has been released in
a stable version.
[explicit instantiation]: https://github.com/dart-lang/language/blob/master/accepted/future-releases/constructor-tearoffs/feature-specification.md#explicitly-instantiated-classes-and-functions
Explicit generic method instantiations are only available as part of the 2.15
[language version](https://dart.dev/guides/language/evolution). To use this
feature, you must set the lower bound on the sdk constraint for your package
to 2.15 or greater (if using a beta preview release, an sdk constraint of
`>=2.15.0-0` must be used).
[Constructor tearoffs]:
https://github.com/dart-lang/language/blob/master/accepted/future-releases/constructor-tearoffs/feature-specification.md
[Explicit instantiation]:
https://github.com/dart-lang/language/blob/master/accepted/future-releases/constructor-tearoffs/feature-specification.md#explicitly-instantiated-classes-and-functions
- **[Generic instantiation of function objects][Object instantiation]**: **BETA PREVIEW**
Generic function instantiation was previously restricted to function
declarations. For example, as soon as a function had already been torn
off, it could not be instantiated:
- **[Generic instantiation of function objects][object instantiation]**: Generic
function instantiation was previously restricted to function declarations. For
example, as soon as a function had already been torn off, it could not be
instantiated:
```dart
X id<X>(X x) => x;
@ -240,19 +206,6 @@
}
```
The new generic instantation of objects feature is currently in **BETA
PREVIEW**. The feature is enabled in beta releases only, and is still subject
to breaking changes. It is not fully supported by all tools and there may be
known issues with the tool support. Feedback on the feature is welcome, but it
is not recommended that production code use the feature until it has been
released in a stable version.
Generic instantiation of objects is only available as part of the 2.15
[language version](https://dart.dev/guides/language/evolution). To use this
feature, you must set the lower bound on the sdk constraint for your package
to 2.15 or greater (if using a beta preview release, an sdk constraint of
`>=2.15.0-0` must be used).
[Object instantiation]: https://github.com/dart-lang/language/pull/1812
- Annotations on type parameters of classes can no longer refer to class members
@ -282,7 +235,7 @@
f(int? i) {
var iIsNull = i == null;
if (!iIsNull) {
print(i + 1); // OK, because `i` is known to be non-null
print(i + 1); // OK, because `i` is known to be non-null.
}
}
```
@ -293,7 +246,7 @@
lacked an explicit type.
To avoid causing problems for packages that are intended to work with older
versions of Dart, the fix only takes effect when the "constructor tearoffs"
versions of Dart, the fix only takes effect when the "constructor tear-offs"
language feature is enabled.
[#1785]: https://github.com/dart-lang/language/issues/1785
@ -324,72 +277,17 @@
instance variable, and it brings the implementation behavior in line with
the specification in all other cases.
- **Function object canonicalization and equality**
Several corner cases in the area of function object canonicalization and
function object equality have been updated, such that all tools behave in
the same way, and the behavior matches the specification.
- **Function object canonicalization and equality**: Several corner cases in the
area of function object canonicalization and function object equality have
been updated, such that all tools behave in the same way, and the behavior
matches the specification.
In particular, function objects are now equal when they are obtained by
generic instantiation from the same function with the same actual type
arguments, even when that type argument is not known at compile time.
When the expressions are constant then said function objects are identical.
Constant expressions are treated as such even when they do not occur in a
constant context (e.g., `var f = top;`). Here are the main cases where the
behavior has been adjusted:
```dart
void top() {}
X? genericTop<X>() => null;
class A {
static void stat() {}
static X? genericStat<X>() => null;
void inst() {}
X? genericInst<X>() => null;
}
const int? Function() cIntTop1 = genericTop;
const int? Function() cIntStat1 = A.genericStat;
int? Function() vIntTop1 = genericTop;
int? Function() vIntStat1 = A.genericStat;
int? Function() vIntTop2 = genericTop;
int? Function() vIntStat2 = A.genericStat;
String? Function() vStringTop = genericTop;
String? Function() vStringStat = A.genericStat;
void main() {
var a = A();
int? Function() vIntInst1 = a.genericInst;
int? Function() vIntInst2 = a.genericInst;
// All true (used to be false).
identical(cIntTop1, vIntTop2);
identical(cIntStat1, vIntStat2);
identical(vIntTop1, vIntTop2);
identical(vIntStat1, vIntStat2);
vIntInst1 == vIntInst2;
<X>() {
X? Function() vXTop1 = genericTop;
X? Function() vXStat1 = A.genericStat;
X? Function() vXTop2 = genericTop;
X? Function() vXStat2 = A.genericStat;
X? Function() vXInst1 = a.genericInst;
X? Function() vXInst2 = a.genericInst;
// All true (used to be false).
vXTop1 == vXTop2;
vXStat1 == vXStat2;
vXInst1 == vXInst2;
vXTop1 == vIntTop1;
vXStat1 == vIntStat1;
vXInst1 == vIntInst2;
}<int>();
}
```
constant context (e.g., `var f = top;`).
### Core libraries