Call to `super == x` should allow null, even if the resolved `operator ==` method does not allow it.

[stereotype441]

Consider the following code:

class C {
  bool operator==(Object other) => true;
}
class D extends C {
  bool operator==(Object? other) => super == other;
}
main() {
  print(D() == D());
}

This is accepted by the analyzer, but rejected by the CFE. The CFE's error message is:

../../tmp/test.dart:5:46: Error: The argument type 'Object?' can't be assigned to the parameter type 'Object'.
 - 'Object' is from 'dart:core'.
  bool operator==(Object? other) => super == other;

@leafpetersen and I believe this code should be accepted, because the behavior of super == other has similar null-handling rules to the behavior of ordinary equality checks; that is, if other is null, then super.operator== is not invoked; therefore, it is ok to have a nullable type on the RHS of super == even if the corresponding operator== method declares its argument to be non-nullable.

Note that the NNBD spec is not entirely clear about this yet; I will shortly send a pull request to add this text (or something similar):

Similarly, consider an expression e of the form super == e2, inside a class
C, where the static type of e2 is T2. Let S be the type of the formal
parameter of operator == in the super-interface of C. It is a compile-time
error unless T2 is assignable to S?.

I'll also add some language tests if we don't have some already.

[stereotype441]

@johnniwinther

[lrhn]

Agree that it should work. The == operator doesn't directly call the operator== method. It removes null as a possible value before calling.

Not all types can be non-nullified at the type level.

class C {
  bool operator==(Object other) => false;
}
class D extends C {
  bool foo(FutureOr<int?> o) => super == o;
}

I'd prefer if this compiles even though "o without null" doesn't have an expressible type (NON_NULL(FutureOr<T?>) is FutureOr<T?> again). (That's why the phrasing "T is assignable to S?" is better than *NON_NULL(T) is assignable to S.")

What if it also overrides C.operator== covariantly:

class C<T extends FutureOr<int?>> {
  bool operator==(covariant T other) => false;
}
class D extends C<FutureOr<int>> {
  bool foo(FutureOr<int?> o) => super == o;  // bad 
}

I can't hack up a combination where your modified text will statically detect any problem which wouldn't also cause a run-time error. I think it will work.

[eernstg]

That's why the phrasing "T is assignable to S?" is better

Exactly, that wording eliminates the problem about "not being able to remove Null from some types" (both in the old text about e1 == e2, and in the new text, dart-lang/language#1070, about super == e).

About soundness: When T <: S? and null is eliminated by the semantics, the actual argument will have type S when/if the body starts executing.

And for optimality: If T <\: S? (that is, T <: S? does not hold) then assume that there is a witness, that is, an object o that has type T and doesn't have type S?. If o is not null then it does not have type S, and it can be the actual argument when the body starts executing, which is a soundness violation. So T <: S? is the most permissive requirement that we can have.

[johnniwinther]

What about src/Language/Expressions/Equality/evaluation_super_t02:

class S {
  operator ==(other) {
    Expect.fail('operator== invoked with $other argument');
    return false;
  }
}

class C extends S {
  test() {
    dynamic n = null;
    Expect.throws(() { super == n; }); // expects type error `Null` is not a subtype of `Object`
  }
}

main() {
  new C().test();
}

Is it a valid expectation?

[eernstg]

I'd say no. Evaluation of super == n detects that n evaluates to null and never invokes any operator ==, so it does not throw as expected. It is implied that the code uses null safety, but the outcome should be the same also without null safety.

[lrhn]

Agree. super == x should work the same as this == x except that the operator== possibly being called is the one from super, not from this.