As the title says, I find it useful to be able to overload operators. Is it possible to also change the way the operators are parsed by specifying the precedence and associativity of overridden operators?
|
|
No, you can't do that and that's a good thing. Operator overloading already has enough potential to make code unreadable without being able to change precedence or associativity. If you even want to do that you are probably abusing operator overloading and should use normal functions instead. |
|||||
|
|
No. While it may at first sight seem to make sense, if you think a little more, it becomes muddy to the point that it's a bad idea. First note that the language isn't defined by using a precedence grammar, but a more classic BNF. I'm not sure that the behavior of But the major issue is that you are changing the priority and associativity of overloaded operators, not defining the priority and associativity of new operators used only for your types. Do you want your changes to be applicable for all uses, or just for your overload? You'll probably agree that the first option is a sure receipt for trouble. The other isn't much better. How to you know it's your overload which should be considered before doing overload resolution, which need parsing and thus associativity and priority to be known. |
||||
|
|
|
No. Besides making code unreadable, it would make the language more ambiguous and deeply context-dependent because you would not be able to associate parameters with function calls until after you know all the operators available. Consider the expression
where all
This could be interpreted two different ways
or
With global precedence and associativity rules, the compiler can commit to the first interpretation during parse, but with overridable associativity/precedence, there's no way to figure out how to decompose tokens into function calls until you know all the available operator signatures. This doesn't make the language impossible to parse (although there are more programs that have to be rejected as untypable) but it would make it slower to compile, and harder to read. |
||||
|
|