Should an `is FutureOr<T>` test make `T` a type of interest?

[eernstg]

Following up on #4361, here comes a similar consideration:

We might want to make T a type of interest when FutureOr<T> is a type of interest. This is motivated by the fact that we already do the same thing for the other union type T?. With FutureOr, the other operand may even be considered: When FutureOr<T> is of interest, Future<T> might also be of interest.

FutureOr<int> bar() => 42;

Future<int> foo(bool urgent, FutureOr<int> x) async {
  if (urgent) {
    if (x is Future<int>) x = 24; // Don't await it!
  } else {
    x = await x;
  }
  x.isEven; // This should be possible here.
  ...
}

This example may be somewhat artificial, but it illustrates that the type int could be of interest based on the fact that FutureOr<int> is already on the table.

Finally, we could consider making FutureOr<T> of interest whenever T is of interest, or Future<T> is of interest. This one seems more far-fetched because it might introduce futures into a context where absolutely nothing points in that direction. Nevertheless,

[lrhn]

My gut feeling is not to, because it gets messy. But I think it's actually a good idea.

Object o = ...;
if (o is FutureOr<int>) {
  o = await o;
  // o is int, because it's of interest, and `await FutureOr<int>` has type `int`.
}

If we do that, then a declaration of FutureOr<int> f; should make both Future<int> and int types of interest for f right from the start.
Otherwise starting with FutureOr<int> f; and doing if (f is Future<int>) f = await f; would not promote to int, because is Future<int> does not make int a type of interest.
So the implication would be FutureOr<T> is of interest => T and `Future are of interest.
That allows the above and:

FutureOr<int> f = ...;
if (f is int) f = Future.value(f); // Promotes to `Future<int>`, if of interest to `FutureOr<int>`.

It is an option, and it is consisitent: If a union type is of interest, then so is each component type.
(But if we are consistent, then int? i would make both int and Null be of interest. Today it's only int.

double? o = 42.0;
if (o != null) {
  use(o);
  o = null;
}
// o has type Null. It's not wrong, it's just a bad context type for further assignment
o = 42; // Should use `double` as context type, would use `Null` using today's rules.

If we compare it to what I want for nullability, which is that both T? and NonNull(T) become of interest when checking for T (or whichever is not equivalent to T, and is still a subtype of the declared type), then that's not consistent.

That would correspond to is int making FutureOr<int>, and through that Future<int>, types of interest, which I am not sure is a good idea.

Object o;
if (o is int) {
  o = Future.value(o); // De-Pro-mote to `Future<int>`?
} else if (o is Future<int>) {
  // Success.
} else {
  o = Future<int>.value(0);
}

If we want this to actually promote to Future<int>, even though we checked for int before we made Future<int> a type of interest, then it's fine.
I don't think it's needed, this is a much too convoluted way to write it, just start with if (o is! Future<int>).

If we worry that we can infer too many types of interest, then we should keep it down.
If not, then anything remotely related to what the user has asked for might be reasonable. They have shown an indirect interest. (And Future<int> is just an "asynchronous int", so it's morally as interesting as int. Maybe.)

The risk is promoting at some assignment where the user didn't expect it. I have a hard time coming up with an example that doesn't feel contrieved, or where the user wouldn't actually prefer the promotion.