Variables with a Generic type bound by an extension type don't get null promotion about sdk

[eernstg]

.. sounds like the current bug according to the spec is in the CFE not the Analyzer, but we may change the spec to agree with the CFE?

The specification does not specify that it is allowed to invoke an extension method whose on type is nullable on a potentially nullable receiver, and this means that we need to adjust the specification in any case. This behavior has been implemented for several years, and it would just be a matter of removing this unwanted and unimplemented error from the specification, such that it is aligned with the implementations.

extension on int? {
  void foo() => print('Fooing!');
}

void main() {
  int? iq;
  iq.foo(); // OK!
}

Similarly, we just need to say in the specification that it is not an error to invoke an extension type member m on a receiver whose type is said extension type, even in the case where it is potentially nullable.

extension type E(int i) {
  void foo() => print('Fooing!');
}

void main() {
  E(1).foo(); // OK.
}

Again, this is already the implemented behavior. However, the difference comes up when we consider related types, in particular when the receiver type is a type variable whose bound is such an extension type:

extension type E(int i) {
  void foo() => print('Fooing!');
}

void f<X extends E>(X x, X? xq) {
  x.foo(); // Analyzer: Error.
  if (xq == null) return;
  xq.foo(); // Analyzer: Error.
}

void main() {
  E(1).foo(); // OK.
  f(E(2), E(3));
}

In this case it is the implemented behavior of the CFE, but it is not the implemented behavior of the analyzer.

So I'd recommend that we discuss the changes to the specification in dart-lang/language#3549 (hopefully we can agree on allowing all of the above examples), and then adjust implementations in those (small) ways that are needed.

So perhaps this issue should be blocked on dart-lang/language#3549?

[eernstg]

E is a potentially nullable type (extension types do not have Object as a superinterface unless they are specified to have it). This will suffice to establish a situation where the invocation is accepted (we've eliminated the tricky part):

extension type E(C c) implements Object {
  void e() {}
}

So the question is whether it is correct for the static analysis to report the unconditional invocation of e on a receiver of type T when E doesn't have implements Object. I created dart-lang/language#3549 in order to have this discussion.

The rule in the null-safety feature specification says that it is an error to have an unconditional member access (invocation or tear-off) on a receiver whose static type is potentially nullable and not dynamic. I argue that we must change this: (1) it should be OK to access an extension member of an extension whose on type is nullable (and this is indeed allowed by our tool chain), and (2) it should be allowed to access extension type members when the receiver static type is or is bounded by said extension type even when that extension type is potentially nullable.

This issue could then be considered to be a duplicate of dart-lang/language#3549.

Interestingly, the extension type itself gets the treatment that I'm asking for:

class B<T extends E> {
  void b(T? t) {
    if (t == null) return;
    // `t` is promoted to have type `T`.
    E t2 = t; // OK, `T <: E`.
    t2.e(); // Sure, no problem! ;-)
  }
}

[natebosch]

This issue could then be considered to be a duplicate

I think resolving that issue would resolve this one too. I do think we should separately track the fact that CFE and Analyzer don't agree about this code currently. It sounds like the current bug according to the spec is in the CFE not the Analyzer, but we may change the spec to agree with the CFE?