Breaking change to await, update to flatten. #2333
Conversation
Changes **flatten** to be specified for a static type which is a type variable. Changes `await` to throw when provided a `Future` value of a type that could provide an unsound value if awaited. This differes from the current specification, which instead treats the future as a value, so `await someFuture` can evaluate to `someFuture`. It also differs from the current implementation, which awaits `someFuture` to its value, whether the result is sound or not. The result *can* be sound. Compare: ```dart Object o = await (Future<Object?>.value(3) as FutureOr<Object)); ``` which ends up not breaking soundness, with ```dart Object o = await (Future<Object?>.value(null) as FutureOr<Object)); ``` which currently does break soundness. This change will make both into runtime errors. (The alternative, and current specification, to make both expression evaluate to the future itself, is considered just as error prone and harder to debug, since a type error is likely happen further downstream when the `Object` is unexpectedly still a `Future`.)
There was a problem hiding this comment.
LGTM, recommending some changes, for consistency with the rest of the language specification.
I also suggested several changes for the definition of \flatten, in order to make it complete for null safety (I don't think we should specify flatten in a new way for the legacy language, so the new definition of flatten should be the full null safety thing). But this creates some issues: We need to use a \ref{...} to a section that doesn't exist in the current specification, and we need to add a command to dart.sty.
Co-authored-by: Erik Ernst <[email protected]>
Co-authored-by: Erik Ernst <[email protected]>
Co-authored-by: Erik Ernst <[email protected]>
Co-authored-by: Erik Ernst <[email protected]>
Co-authored-by: Erik Ernst <[email protected]>
|
Visit the preview URL for this PR (updated for commit 9733ae8): https://dart-specification--pr2333-flatten-await-s0p1ts7w.web.app (expires Thu, 14 Jul 2022 11:18:59 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 6941ecd630c4f067ff3d02708a45ae0f0a42b88a |
| Otherwise | ||
| (\commentary{when $R$ does not implement \code{Future}}), | ||
| let $f$ be an object whose run-time type implements \code{Future<$T$>}, | ||
| which is completed with the value $o$. |
There was a problem hiding this comment.
Nit. This doesn't actually say what behavior the f object has.
Changes flatten to be specified for a static type which is a type variable.
Changes
awaitto throw when provided aFuturevalueof a type that could provide an unsound value if awaited.
This differs from the current specification, which instead treats the future as
a value, so
await someFuturecan evaluate tosomeFuture.It also differs from the current implementation,
which awaits
someFutureto its value,whether the result is sound or not.
The result can be sound. Compare:
which ends up not breaking soundness, with
which currently does break soundness.
This change will make both into runtime errors.
(The alternative, and current specification,
to make both expression evaluate to the future itself,
is considered just as error prone and harder to debug,
since a type error is likely happen further downstream
when the
Objectis unexpectedly still aFuture.)