[ruby-core:48421] [ruby-trunk - Feature #6678] Precedence of ^ operator

Issue #6678 has been updated by trans (Thomas Sawyer).


> gives me a 404 (There isn't a GitHub Page hosted here, sorry.).

It was just the same write-up with different formatting. So nothing missed.

> This sounds to me as if you think that backwards compatibility wasn't a 
> problem at all. But who is going to fix all these scripts out there that 
> rely on the current precedence?

It's a valid reason. I was just saying what a I concluded putting that particular reason aside. It is important, of course. How much code would break if `^` had a high precedence? It can be hard to say. I would expect very little given typical usage I've encountered. Of course, there will still be cases, even if few.

> This is third-hand knowledge, and not in any way specific to "^" ...

Pretty sure Dennis Ritchie did specifically say that the bitwise operators should have not been lower than `==` and that he would do it differently if he had to do over again. Inferring from his statements about this, it seems operator precedence arose more organically rather than being fully rationalized out. I too wish would could ask him.

----------------------------------------
Feature #6678: Precedence of ^ operator
https://bugs.ruby-lang.org/issues/6678#change-31742

Author: trans (Thomas Sawyer)
Status: Rejected
Priority: Normal
Assignee: 
Category: core
Target version: Next Major


I wrote about this here: http://trans.github.com/2009/12/13/a-failure-of-precedence.html (or https://github.com/trans/trans.github.com/wiki/2009-12-13-a-failure-of-precedence if you prefer)

In short I would like to see `^` operator move up in precedence to be the same as `**`. We need another option besides `**` at the top of precedence list and `^` fits the bill well since many languages already think of it as "power of".

Of course, this has downside that effects current use for XOR definition. A new operator would be needed for that but `^` could alias it by default, so only thing that changes is precedence. Thankfully XOR is not among the most commonly used operators and often when used the precedence will be okay either way. So there should be very few cases where new operator or parenthesis will need to be put in.

Ultimately it would be great if precedence could be controlled on per-class basis. But that is big change, and might not be altogether practical. So I propose this one modest adjustment instead in which it would be an improvement.



-- 
http://bugs.ruby-lang.org/