[Breaking Change] Fix pattern context type schema for cast patterns.

[stereotype441]

Change Intent

The pattern context type schema for cast patterns will be changed from Object? to _ (the unknown type), to align with the specification.

Justification

When the compiler encounters a pattern variable declaration or a pattern assignment, it derives a pattern type schema from the pattern on the left hand side of the =, and uses it for type inference of the expression on the right hand side of the =. A type schema is like a type, except that it can have holes in it representing parts of the type that are not yet known. (These holes are written as _, which is called the "unknown type"). For example, in the pattern variable declaration:

var (List<num> x, [...y]) = ([1], [2]);

The pattern type schema is (List<num>, List<_>); this constrains the type of [1] to be List<num>, so it is treated as though the user wrote <num>[1]. But it doesn't place any constraint on the type of [2] (other than the fact that it must be a list of some sort), so type inference concludes that the type of [2] is List<int> (because the list contains all integers), and so it is treated as though the user wrote <int>[2].

When the patterns feature was added to Dart in 3.0, a small implementation error was made in the computation of pattern type schemas. The pattern type schema for a cast pattern is specified to be _. So, for example, in the pattern variable declaration:

var [x as int, y as double] = [1, 2.0];

The intention was for the pattern type schema to be List<_>, and so the list literal [1, 2.0] would take on the type required by its elements, namely List<num>. That is, it would be compiled as though the user had written <num>[1, 2.0].

However, what was actually implemented was that the pattern type schema for a cast pattern is Object?. So in the example above, the pattern type schema is List<Object?>, and so the list literal [1, 2.0] is interpreted as <Object?>[1, 2.0].

The proposed change will bring the implementation in line with the specification.

Impact

This change is not expected to make any difference in practice. When it was tested on the google internal code base, only a single line of code was affected at all, and the only effect on that code was that a cast pattern that was previously thought to be necessary was correctly detected by the compiler as unnecessary (resulting in a warning, not an error).

However, it's theoretically possible that the change could cause a type to be inferred differently in a way that causes a code breakage. For example, this code is accepted today:

main() {
  var (x && [y as int]) = [0]; // (1)
  x.add('foo');
}

It's accepted because the pattern type schema for the declaration at (1) is List<Object?>, and hence [0] is interpreted as <Object?>[0], so x.add('foo') is allowed.

But when the change is made, this code will be rejected, because the pattern type schema for the declaration at (1) will be List<_>, and hence [0] will be interpreted as <int>[0], and it is not allowed to add a string to a list of int.

Mitigation

In the unlikely event that some code is affected by this change, the old functionality can be restored by adding explicit type annotations. For instance, in the above example, the code could be changed to:

main() {
  var (x && [y as int]) = <Object?>[0]; // (1)
  x.add('foo');
}

[itsjustkevin]

@vsmenon @grouma @Hixie could you take a look at this breaking change request?

[Hixie]

no objection

[grouma]

SGTM.

[vsmenon]

@leafpetersen - what is your recommendation on this?

[leafpetersen]

LGTM

[vsmenon]

lgtm

[stereotype441]

Fixed by 3636c8a.