After null-safety, compiler seems to have problems correctly "demoting" ternary expression

[mateusfccp]

I don't know if this is expected or is a bug.

Consider the following:

Base<Object?> test1(int n) {
  return n == 1 ? A<String>() : B<int>();
}

Base<dynamic> test2(int n) {
  return n == 1 ? A<String>() : B<int>();
}

class Base<T> {}
class A<T> extends Base<T> {}
class B<T> extends Base<T> {}

In the case above, the compiler don't know that A<String> and B<int> are both Base<Object?> or Base<dynamic> and thus the ternary expression will be demoted to Object, giving a compilation error on both test1 and test2.

A value of type 'Object' can't be returned from the function 'test' because it has a return type of 'Base<Object?>'.

Using a explicitly cast will work:

// In this case, however, the linter will complain that the cast is unnecessary.
Base<Object?> test1(int n) {
  return n == 1 ? A<String>() as Base<Object?> : B<int>() as Base<Object?>;
}

Base<Object?> test1(int n) {
  return (n == 1 ? A<String>() : B<int>()) as Base<Object?>;
}

This worked before null-safety.

[leafpetersen]

This worked before null-safety.

This "worked" before null-safety. :)

The computed type here is the same before null-safety and after null-safety - Object in both cases. Pre-null-safety, the system just inserted an implicit cast for you, but in the null-safety release we disallowed implicit downcasts, and so you now get an error.

It would be nice to do a better job with the upper bound computation, but the nature of the Dart type system makes upper bounds extremely challenging, and so we often fall into less than ideal solutions.

For conditional expressions specifically, I would like us to stop using upper bounds when we don't have to, which would solve your example. See my comment on this issue for details.

I'll close this issue in favor of #1618 , feel free to follow up there.

[mateusfccp]

Thanks, @leafpetersen, it does makes sense