type promotion failing with assignment expression with some branching / ternary expressions

[mmcdon20]

Consider the following code.

Iterable<num> a(Iterable<num>? i) => i = (true ? <int>[] : <double>[]); // promotion works
Iterable<num> b(Iterable<num>? i) => i = (true ? <int>[] : <int>{});    // promotion works
Iterable<num> c(Iterable<num>? i) => i = (true ? <int>[] : <double>{}); // promotion fails!

Here functions a and b compile and run as expected, however function c results in an error.

A value of type 'Iterable<num>?' can't be returned from the function 'c' because it has a return type of 'Iterable<num>'.

[lrhn]

Working as designed.

The UP function can recognize that the upper bound of List<A> and List<B> is List<UP(A, B)>, but only when the head-type is precisely the same.

Otherwise it tries to find a common superinterface.

List<int> and Set<int> both have the superinterface Iterable<int>, so it finds that.

For List<int> and Set<double>, the only common superinterface is Object, and that used to be the type of the third conditional expression here.

A somewhat recent improvement used the context type, Iterable<num>?, as a fallback in the case where the result of UP is not valid for the context, but each type is.
The context of an assignment's value expression is the type of the variable being assigned to, not the context that the assignment expression itself occurs in.
So here it's Iterable<num>?, which becomes the type of the conditional expression, allowing the assignment to be valid.

Then that type cannot be returned.

[mmcdon20]

Is Iterable<UP(A, B)> not possible?

[FMorschel]

How does an expression with only non-nullable branches like the above have a nullable static type?

[lrhn]

There are two possible static types for a conditional expression:

• the UP of the static type of the two branches.
• the context type of the expression.

The UP here is Object, the context type is Iterable<num>?.

Since the UP type is not assignable to the context type, and both branches' types are subtypes of the context type, the context type is used.

That's is the entirety of the algorithm. The context type happens to be nullable, but there is no attempt to find a better type, because it's enough to satisfy the only requirement that the algorithm locally knows about.

I guess it would be possible to make the type non-nullable if both branches are non-nullable.
It would help in this particular case, and shouldn't hurt, but it also feels fairly ad-hoc.

@stereotype441

[lrhn]

@mmcdon20
The algorithm does not try to find a shared superinterface with different instantiations. It's not given that there is a unique such interface.

If it tried, it'd very likely be possible to design type hierarchies where the recursive UP would keep recusing forever. The current algorithm is guaranteed to terminate.