[cfe] Type `void` is allowed in `[]=` operator

[sgrekhov]

The code below produce no issues in the analyzer but errors in CFE.

main() {
  Map<void, int> m1 = <void, int>{};
  void key = 0;
  m1[key] = 1; // Error: This expression has type 'void' and can't be used.

  Map<int, void> m2 = <int, void>{};
  void value = 0;
  m2[2] = value; // Error: This expression has type 'void' and can't be used.
}

Acording to the specification key and value of type void in the []= operator are both allowed.

See also #57070.

[eernstg]

Right. It could be argued that even though operator []= is a method with two parameters, the syntax m1[key] = 1 is so different from the regular myFunction(arg1, arg2) that it should be given special treatment.

(For example, e1 == e2 is not treated exactly the same way as an invocation of a method with one argument.)

However, I don't think there is any particular reason why we would want to make an exception for this case, so I'd recommend that we consider the spec rule "an actual argument of type void can be passed to a parameter of type void" to be applicable to this case as well, and then we shouldn't have the errors.

[lrhn]

Having a non-empty map with void as key type is a bad idea to begin with.
Following the rule that a void typed expression may occur in a void-typed context, this does seem like it should be allowed.
(I never liked that rule to begin with, so I'd be fine with exceptions, but the it would be the consistent specification.)

The spec phrasing could use a little tweaking:

  If $s$ is an \synt{assignableSelector} of the
  form \code{.\id} or \code{?.\id}
  where the static type of the identifier \id{} is \VOID,
  $e_1$ may have type \VOID.
  Otherwise, if $s$ is an \synt{assignableSelector} of the form
  \code{[$\,e_0\,$]} where the static type of
  the first formal parameter in the statically known declaration
  of operator \code{[]=} is \VOID,
  $e_0$ may have type \VOID.
  Also, if the static type of the second formal parameter is \VOID,
  $e_1$ may have type \VOID.

The "where the static type of the identifier \id{} is \VOID" should probably say
"where the parameter type of the statically know setter denoted by \id{} is \VOID". The identifier is not an expression, it doesn't have a static type. It's a member accessor on an expression which does have a static type, and it's invoking that type's setter for the id property. (Even if we allow ourselves to use a shorthand like "The type of the id identifier of type T", that would be more likely to refer to the getter return type, and is at least ambiguous when the types can differ between getter and setter.)

(Ceterum autem censeo that void expressions should not be allowed anywhere where their value is not immediately discarded.)

[eernstg]

Good point! I think we discussed "where the static type of the identifier \id{} is \VOID" when it was added to the language specification and it was accepted because it seemed to avoid some verbosity, but your new wording isn't particularly verbose.

In any case, there is still no reason to treat []= and [] differently than other instance methods (and []= is even mentioned specifically in the given spec paragraph). So the errors mentioned in the original posting should still not be reported.

[lrhn]

The []= operator is more like a setter than a method, at least for the second operand.
We should allow a void typed second argument in the same cases where we would allow it for a setter. (I don't actually know which cases that is, probably just then the setter parameter type is void.

[eernstg]

I think we'd then expect the following to succeed:

class IntVoid {
  void operator []=(int _, void _) {}
}

class VoidInt {
  void operator []=(void _, int _) {}
}

class VoidVoid {
  void operator []=(void _, void _) {}
}

void main() {
  void v = null;
  IntVoid()[0] = v;
  VoidInt()[v] = 0;
  VoidVoid()[v] = v;
}

Currently, this succeeds with the analyzer, but the CFE reports that v has a value that can't be used, at all four occurrences. Note that the following succeeds with the analyzer as well as the CFE:

set setter(void v) {}

void main() {
  void v = null;
  setter = v;
}

This is consistent with the perspective that the right hand side of an assignment that invokes a setter is treated as an actual argument to the formal parameter of said setter, which would allow both e2 and e3 to have type void in an expression of the form e1[e2] = e3 when the corresponding formal parameters have type void.

[lrhn]

ACK, and similarly, the expression inside the [..] of the [] and []= operators is also a parameter, and should be treated like one. The second paramter to []= can be treated as a setter or a parameter, but it should give the same result. (Allowing void in a position where its value gets propagated ... yuck!)

[eernstg]

Let's get this one settled: dart-lang/language#4454.