Should enhanced type promotion track when a type is exactly Null?

[stereotype441]

The current (work in progress) implementation of enhanced type promotion allows a != null check to promote a type to non-nullable, e.g.:

void f(int? i) {
  if (i != null) {
    print(i.isEven); // Ok, since the type of i is promoted to `int`
  }
}

In principle, we could also allow an == null check to promote a type to Null, e.g.:

void f(int? i) {
  if (i == null) {
    print(i?.isEven); // ERROR: type `Null` has no method `isEven`
  }
}

But I'm not sure whether it's a good idea or not. Arguments in favor:

• It's not a lot of implementation work.
• It might help the user by rejecting code at compile time that's almost certainly buggy.

Arguments against:

• It's not a strictly necessary feature to make NNBD useful.
• It rejects code that wouldn't necessarily produce an error at runtime (see the example above).
• It's not really in the spirit of type promotion; whereas other type promotions promote to a type that is strictly more useful (allowing the user to avoid inserting redundant casts), promoting to the Null type is strictly less useful, so it wouldn't allow the user to avoid inserting any casts.

[eernstg]

Promotion via value comparison is a weird corner case:

Null gets a very special treatment during evaluation of e1 == e2, and we are already using that to justify promotion based on x != null (if that's true then x is definitely not null). It is also guaranteed that if x == null is true then x is definitely null.

But any expression that actually invokes operator == on a user-defined class instance can of course return whatever it wants. E.g., x == 42 can certainly return true if the value of x is an instance of SomeClass whose operator == makes that choice, so there's no guarantee that x is int would have evaluated to true. Other value comparisons like x == const <int>[] also provide no guarantees, whereas const <int>[1, 2] == x would give us a type guarantee via canonicalization (but that's again a very special case), and 42 == x could provide a guarantee because the platform controls operator == for the instance obtained from evaluating 42 (special casing again). So there is no valid argument for extending value comparison based promotion beyond null (and no need to worry about being inconsistent when we don't do that).

On the other hand, we generally promote based on specific syntactic forms when we have enough information to know that it's sound.

On balance I think it would make sense to promote x to Null on x == null: That will consistently exploit the special treatment of null with ==, and we can't make the case that, for consistency, we should go further and promote on other values than null.

PS: I would expect the response to i?.isEven to be more like "error: Accessing a member of Never", cf. nnbd static errors. In that sense it's actually more like a dead code diagnostic.

[munificent]

I think it's reasonable. Consider:

void f(int? i) {
  if (i != null) {
    print("not null");
    return; // <--
  }

  print(i?.isEven); // ???
}

The only way to reach the last line is when i is definitely not null. I think it would be good to tell users that this code isn't going to do anything useful, and promotion to Null would do that.

[leafpetersen]

This is actually already specified here. That part of the specification should possibly be folded into the flow analysis based promotion spec though.

[lrhn]

As linked above by @leafpetersen, the answer was yes.