Quick-fix return type could consider `==` and `contains` #60618

FMorschel · 2025-04-24T19:14:05Z

Consider this code:

void f(int value, String txt) {
  value == txt.foo;
}

It will have a quick-fix for creating a foo getter. The output will look like:

extension on String {
  Object get foo => null;
}

Although this is technically accurate, couldn't we suggest int as a return type here instead, @bwilkerson?

The same rule would apply for Iterable.contains/Map.containsKey/Map.containsValue in that case:

void g(List<int> value, String txt) {
  if (value.contains(txt.option2)) {}
}

The text was updated successfully, but these errors were encountered:

bwilkerson · 2025-04-24T21:06:43Z

It's perfectly valid to write

void f(int value, String txt) {
  value == txt;
}

It's pointless, because we know that the result will always be false, but that's only because neither String nor int can have subtypes and we know what the operator == does when the left operand is an integer.

However, consider

void f(A a, B b) {
  a == b.foo;
}

The expression b.foo could return any type and it's plausible that the operator could return true.

So, we treat the operator the same way we'd treat any other method, we use the type of the corresponding parameter (which in this case is Object) to get the most specific type that can't be wrong.

FMorschel · 2025-04-24T21:16:23Z

I guess if we had a hierarchy like:

A -> B -> OtherTypes

And we were doing:

void f(A a, B b) {
  a.foo == b
}

Even though the above would only return true when foo is at least B (without override), foo could still return any A or something it implements and it would sometimes be true.

I just wanted us to skip some steps for the user if they want that operation to return a true. It's fine the way it is then. Thanks!

bwilkerson · 2025-04-24T21:24:10Z

Consider a slightly larger example:

class A {
  C get foo => C();
}

class B {}

class C {
  @override
  bool operator ==(Object other) => other is C;
}

void f(A a, B b) {
  a.foo == b;
}

I think you're making assumptions about == that aren't enforced by the language.

Also, note that unrelated_type_equality_checks is a lint. It's a useful lint if you follow the standard conventions, but has lots of false positives if you don't.

(I suppose we could change the behavior for == if the lint is enabled, but I'm not sure there's enough value in it to warrant the cost.)

FMorschel added the area-devexp For issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages. label Apr 24, 2025

FMorschel closed this as completed Apr 24, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Quick-fix return type could consider `==` and `contains` #60618

Quick-fix return type could consider `==` and `contains` #60618

Quick-fix return type could consider == and contains #60618

Quick-fix return type could consider == and contains #60618

Comments

Quick-fix return type could consider `==` and `contains` #60618

Quick-fix return type could consider `==` and `contains` #60618