Quick-fix Wrap with extension override when overriding an existing member

[FMorschel]

If an extension that overrides a built-in member is available in scope, could we allow a "Wrap with extension override" fix for it?

class A {
  int operator %(int other) => other;
  int get thing => 0;
}

void main() {
  var a = A();
  a % '';
  String str = a.thing;
}

extension AE on A {
  String operator %(String other) => other;
  String get thing => '';
}

We'd have to be smart about this, but I think it is doable.

CC @bwilkerson

[bwilkerson]

I don't think we'll get a diagnostic, so I suspect that you mean an 'assist', rather than a 'fix'. I say that to test that I'm understanding what you're proposing, not because I care which word you used.

I have two potential concerns for this request.

The first is that it might be too expensive to look to see whether there's an extension member with the same name as a non-extension member every time the selection is inside the name of a member. I seem to recall that this is a fairly expensive operation, and there are a lot of member names in most code. We'd have to do some performance testing to know whether it's a real problem.

The second is that I don't know whether having extension members with the same name as a non-extension member is common enough to justify the cost (implementation, maintenance, cognitive load, etc.).

[FMorschel]

I don't think we'll get a diagnostic, so I suspect that you mean an 'assist', rather than a 'fix'. I say that to test that I'm understanding what you're proposing, not because I care which word you used.

Well, it depends. If you have a more specific (sub-)type at the extension override, then yes, no diagnostic. But my examples above would trigger diagnostics for:

The argument type 'String' can't be assigned to the parameter type 'int'. dart(argument_type_not_assignable)

A value of type 'int' can't be assigned to a variable of type 'String'.
Try changing the type of the variable, or casting the right-hand type to 'String'. dart(invalid_assignment)

So for those, it would be a fix.

The first is that it might be too expensive to look to see whether there's an extension member with the same name as a non-extension member every time the selection is inside the name of a member. I seem to recall that this is a fairly expensive operation, and there are a lot of member names in most code. We'd have to do some performance testing to know whether it's a real problem.

This is the main reason why I've suggested for us to shrink the scope to only look for extensions in-scope (not to import new ones, although that could be improved in the future at the "Add import" fixes to call this one or vice-versa) and for this to be a fix so it would only trigger when there are errors and the user IDE asks if we know how to fix it.

The second is that I don't know whether having extension members with the same name as a non-extension member is common enough to justify the cost (implementation, maintenance, cognitive load, etc.).

I'm not sure either, but I've read in the language issue tracker (here specifically) that users are using extensions as a way of overloading functions/methods, so this could help with that.