proposal: avoid_nullable_equals_parameter

[natebosch]

Description

"The null value will never be passed to operator ==. Use a non-nullable Object parameter"

Details

A definition like bool operator ==(Object? other) causes other classes which override the interface to also accept a nullable argument, even though null will never be passed.

Kind

Style

Good Examples

  @override
  bool operator ==(Object other) =>

Bad Examples

  @override
  bool operator ==(Object? other) =>

Discussion

Mockito codegen currently fails to generate fakes for classes with a nullable argument to operator ==.

The main motivator is that the code is misleading - null can't show up so it's not worth making it look like it can.

[natebosch]

This could perhaps supersede avoid_null_checks_in_equality_operators

If I understand correctly that lint only fires when the argument is nullable.

[natebosch]

There is one place where using Object? is useful, it allows promotion to a generic type when the bound on the generic is also Object?. If the argument is Object then we can't promote to a generic type with no bound.

Example:

class C<T> {
  bool checkStuff(T other) => true;

  @override
  bool operator ==(Object other) => other is T && checkStuff(other);
  //                                                         ^^^^^
  // The argument type 'Object' can't be assigned to the parameter type 'T'.
}

I think it's probably better to find a different pattern for the body than to widen the argument type to get promotion.

[natebosch]

Could also flag no argument dynamic as an unnecessary widening as well.

google/protobuf.dart#675

[srawlins]

+100. One question:

"The null value will never be passed to operator ==. Use a non-nullable Object parameter"

Does this fact come from spec? Or just existing behavior of today's backends?

[bwilkerson]

It's from the spec (the third bullet item):

17.27 Equality equality
Equality expressions test objects for equality.
...
Evaluation of an equality expression ee of the form e1 == e2 proceeds as follows:
• The expression e1 is evaluated to an object o1.
• The expression e2 is evaluated to an object o2.
• If either o1 or o2 is the null object (17.4), then ee evaluates to true if both o1 and o2 are the null object and to false otherwise. Otherwise,
• evaluation of ee is equivalent to the method invocation o1.==(o2).

[srawlins]

Some flutter customer tests violate this so the change is being reverted. #51038

[mateusfccp]

Wasn't this solved by https://dart-review.googlesource.com/c/sdk/+/277700?

[srawlins]

Yes, sorry. Landed, reverted, then re-landed with aad9e57. That commit message says "Fixes #58753" but that doesn't work cross-repos.