Does this test look correct for the currently specified behavior?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Thanks for digging into this topic, this is very useful!
I do think, though, that we should clarify the treatment of user-definable operators (and even `yield`) in order to ensure that we have a consistent design. See also https://github.com/dart-lang/language/issues/4659 and https://github.com/dart-lang/language/issues/4660.
o + v;I'd expect an operand to be treated like the actual argument to a member invocation that it is semantically. So this would not be an error. Similarly for the other cases below.
The allowlist in the language specification does not mention operators other than `[]` and `[]=`. We probably forgot about the situation where the formal parameter of an operator has type `void`.
However, the CFE reports these errors and the analyzer does not, which means that we need to change implementations no matter what. Also, making `o + print('')` a non-error would be a non-breaking change for the CFE (and a non-change for the analyzer).
Do you see any reason why we would not treat all actual arguments the same?
o[v] += v;With the proposed uniform treatment of actual arguments, we wouldn't expect an error here.
no?[v] += v;No error if treating all actual arguments uniformly.
// and operand of `[]` or `[]=` (or both).Typo: 'an' operand.
o..[v] += v;No error if treating actual arguments uniformly.
no?..[v] += v;No error if treating actual arguments uniformly.
S.property += v; // Argument to `C.operator +`, not `[]` or `[]=`.No error if treating actual arguments uniformly.
topProperty += v; // Argument to `C.operator +`, not `[]` or `[]=`.No error if treating actual arguments uniformly.
o + v;These would be similar to the non-generic variants, no errors if actual arguments are treated uniformly.
o[v] += v; // Argument to G.operator+, not []=.No error if uniform.
no?[v] += v; // Argument to G.operator+, not []=.No error if uniform.
// No yielding `void`, even if the element type is `void`.Great catch!
But why would we report an error for yielding void to void, considering that we're happy returning void to void? I created #4660 to clarify this.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |