Type of an if-null or conditional expression should only be the LUB if it's a subtype of the context

[stereotype441]

Consider the following code:

class I {
  void f() {}
}
class J {}
class C extends I implements J {}
class D extends I implements J {}
void test(C c, D d) {
  I x = (c ?? d)..f();
}

The current analyzer and front end reject this code, because they consider the type of c ?? d to be LUB(C, D), which is Object, and Object does not define a method f.

According to #32291 (comment), the LUB should only be used if it is a subtype of the greatest closure of the context; otherwise the greatest closure of the context should be used. So the type of c ?? d should be I and the code should be accepted.

[stereotype441]

We probably can't fix this until after #31792 is fixed, and here's why. Consider the following code:

class C {}
void test(C c, Object o) {
  C x = c ?? o;
}

Currently this gets compiled as C x = (c ?? o) as C;, which is not precisely what we want but has the correct runtime semantics. If we fix this bug without fixing #31792, then the type of c ?? o will be considered to be C, and the implicit downcast will be lost. We need to first fix #31792, so that the code will get compiled as C x = c ?? (o as C);.

[leafpetersen]

Yes, this issue is essentially a clarification/refinement of #31792 as to what the inferred type of sub-expressions should be. The point of #31792 is that the inferred type of an expression should always be a subtype of its context. The point of this issue is that we should use the most precise type available that satisfies that (that is, if we are not forced to downcast, we should not upcast gratuitously).

[leafpetersen]

Also, this is really about more than just the two operators mentioned, though that's the most visible place (and possibly the only place where the implementations aren't doing the right thing).

This is true in general whenever downwards inference "stops" and has to interact with upwards inference either by and downcast, or via a no-op because the upwards type is a subtype of the context type. Examples:

void foo(Object x) {}

// The static type of bar() should be resolved as int, not as Object, even though
// Object is the downwards type, since int <: Object.  This matters for completion
int bar() => 3 
foo(bar()..isEven);

void foo<T>(List<T> x) {}
List<int> l;
// This should infer <int> for the type parameter, even though the downwards
// context in which we infer l is List<?>.  That is, we should resolve l as having
// type List<int>, even though the greatest closure of the context is List<Object/dynamic>.
foo(l);

[srawlins]

This is probably massively stale, but in case its not: @stereotype441 I swear I just saw a proposal or an issue from you regarding using context types in LUB. :)

[stereotype441]

This is probably massively stale, but in case its not: @stereotype441 I swear I just saw a proposal or an issue from you regarding using context types in LUB. :)

Yeah, let's close this out in favor of dart-lang/language#1618.