Breaking Change Request: normalize types and use mutual subtyping for type parameter bounds

[sigmundch]

Planned change

In preparation for null safety, we'd like to roll out several minor breaking changes. Two such changes are about types in the language. These changes are:

• Types objects will now be normalized (see specification for details)
• Subtyping of type bounds in function types will switch from using structural subtyping to use mutual subtyping.

Expected Impact

This affects equality of type objects and some subtyping checks, but the cases where we expect differences are pretty rare and small.

Most of the normalization rules are not visible to Dart programs today (most rules concern null safety features). Only only two rules are visible:

• FutureOr<Object> normalizes to Object (similarly with other top types like dynamic and void)
• FutureOr<Null> normalizes to Future<Null>

This change is visible when comparing or printing .runtimeType of objects involving those two FutureOr types, for example: <FutureOr<Object>>[].runtimeType == <Object>[].runtimeType will now be true.

For subtyping of bounds, this affects checks where the bounds were structurally different but would be subtypes of each other. Again we only expect this to affect cases where FutureOr<Null> or FutureOr<Object> were used within function type bounds.

For example, consider void Function<T extends List<Object>>() and void Function<T extends List<FutureOr<Object>>>(). With structural subtyping these two function types were not comparable, but with mutual subtyping they are both considered equivalent.

Note that there is a lot of overlap between these two breaking changes. With normalization we would start indicating that the two function types above would be subtypes using structural subtyping as well. We however introduce the concept of using mutual subtyping on the bounds to prepare for the future additions that come with null safety, where normalization will no longer be sufficient.

Mitigation

We think the most visible part of this change will be in tests that rely on using .runtimeType.toString() that also mention FutureOr<Null>, FutureOr<Object>, FutureOr<dynamic>, or FutureOr<void>. If those occur, then they will need to be updated to reflect the normalization changes.

[sigmundch]

@franklinyow @mit-mit @vsmenon

[sigmundch]

@Hixie @matanlurey - let us know if you foresee any issues with this for either flutter or angular.

[sigmundch]

@franklinyow - announcement was sent here: https://groups.google.com/a/dartlang.org/forum/#!searchin/announce/breaking$20change%7Csort:date/announce/px2Qfe8UmYc/kclOKC10FwAJ

[lrhn]

How will this affect the "await only futures" lint?
It seems reasonable to await FutureOr<Object>, but not to await Object.

[franklinyow]

cc @Hixie @matanlurey @dgrove @vsmenon for review and approval.

[Hixie]

I am indifferent to things affecting FutureOr<>, it's my assumption that eventually we will be removing FutureOr from the language, adding type unions/intersections, and redefining FutureOr as:

typedef FutureOr<T> = Future<T> | T;

So long as what we're doing here is consistent with doing that on the long term, I'm happy.

[vsmenon]

lgtm

[matanlurey]

LGTM

[franklinyow]

Approved

[sigmundch]

Changes implementing this in the VM, dart2js, and DDC have now landed.