Type inference should always infer the return type of operator []= as void

[stereotype441]

For this code:

class C {
  dynamic operator[]=(dynamic index, dynamic value) {}
}
abstract class I {
  void operator[]=(dynamic index, dynamic value) {}
}
class D extends C implements I {
  operator[]=(dynamic index, dynamic value) {}
}

The front end reports the following error:

Error: Can't infer the type of '[]=': overridden members must all have the same type.
Specify the type explicitly.
  operator[]=(dynamic index, dynamic value) {}
          ^

As discussed in #31756, it would be better to simply infer a return type of void, since returning a value from operator []= is meaningless anyhow. Although this is a small corner case, addressing it seems like it would make the language more consistent, since it would make the type inference rule for the return type of operator []= the same as the type inference rule for the return type of a setter.

@leafpetersen and @lrhn do you agree? This would require changes to the front end, the analyzer, and the language spec. I'm happy to do the front end and analyzer changes.

[eernstg]

Lasse and I agreed when we talked about this earlier today: Yes, the inferred return type should be void, just like it is for setters. Here is a CL for the change that Lasse and Leaf may sign off to get it done.

[eernstg]

The CL has now been landed.

[leafpetersen]

SGTM.

[kmillikin]

This issue affects package yaml when compiling with the common front end.

[stereotype441]

The analyzer was fixed in bb52d1a. This CL should fix the front end: https://dart-review.googlesource.com/#/c/sdk/+/35005

[mraleph]

This still does not work if operator []= contains throw:

   operator []=(int index, value) {
     throw new UnsupportedError("Cannot modify an unmodifiable List.");
   }

(code from package yaml).

[stereotype441]

@mraleph It turns out that your case wasn't broken because of the throw; it was broken because when type inference is required for a parameter, it was triggering the old (broken) type inference logic for the return type. Should be fixed by https://dart-review.googlesource.com/c/sdk/+/37300.