FutureOr conditional expression typing issue about language HOT 7 OPEN

Different from dart-lang/sdk#28783, but basically a dup of dart-lang/sdk#25368 . Definitely something I want to fix when I get a chance. Current behavior allows really bad code, and gives an error on correct code. Sadness.

from language.

@leafpetersen dart-lang/sdk#25368 was closed with "being covered by null safety", but doesn't resolve this issue. Below code still throws a compiler error for the getter in dart 2.14.4.

import 'dart:async';

class X {
  FutureOr<int> get f => true ? Future.value(12) : 13;
}

from language.

I think we could consider this issue as a request for a new rule for UP, located after the FutureOr rules:

• UP(Future<T1>, T2) = FutureOr<T3>, where T3 = UP(T1, T2).
• UP(T1, Future<T2>) = FutureOr<T3>, where T3 = UP(T1, T2).

It is possible that we could combine these rules with the rules about UP(FutureOr..., Future...) and achieve a tighter result, but it might also work just fine to keep all of them.

We do have some prior art for treating union types in this manner:

• UP(T1?, T2) = S? where S is UP(T1, T2).

@leafpetersen, WDYT?

from language.

I removed the 'closed-duplicate' label, because we do seem to have specific elements here that aren't present in dart-lang/sdk#25368.

from language.

Maybe. I'm a little hesitant about introducing FutureOr where there wasn't one to begin with. We'd have to evaluate carefully what side effects result.

from language.

@leafpetersen This looks like a language issue rather than an implementation issue. If you agree I'll move this over to the language repo.

from language.

Note the following perspective on this situation: As long as we do not want to introduce FutureOr in an upper bound computation when it wasn't present in the operand types, the workaround would be to adjust an operand type:

import 'dart:async';

class X {
  FutureOr<int> get f2 => true ? Future.value(12) : 13 as FutureOr<int>;
}

We're basically weighing the inconvenience of doing this in a few locations against the potential danger of having unexpected/unwanted occurrences of types of the form FutureOr<T> for conditional expressions, list/set/map literals, and other locations where upper bound computations take place.

from language.