Getting people to remember the new precedences when writing new code would probably be really hard,

Actually, the proposed precedence should be easier to remember since it groups the bit-wise operators together and places them in a much more logical place in the order. (I'll just set aside my proposed change to the precedence of !, which I have changed my mind about.) I also doubt that most Perl programmers have bothered to memorize the current precedence of these particular operators as it is nearly non-sensical as well as mostly useless. The only thing worth memorizing about the current state is that you need to always use parens when dealing with bit-wise operators. If you do that, then a change in the precedence will have no effect on you.

Like you said, there'd be a flood of "why doesn't my script work?" questions.

I'd really like to see a single production script that would be affected by this change. To do so, it would have to be using code like what you wrote: if(  0 == $mask & $value  ) { which gets parsed as: if(  ( 0 == $mask ) & $value  ) { which computes a value of 1 or 0 (depending whether $mask is 0 or not), then does a bit-wise "and" with $value. When would you ever write code like that? You want to know whether $value is odd, but only if $mask is non-zero? If so, there are much clearer ways to write such code.

Using bit-wise operators on the Boolean results of comparison operators is a pretty useless act. Even the "named unary operators" return values that you are quite unlikely to want to perform bit-wise operations on.

Pretty sneaky of you to retract your proposed change in precedence of ! in composing your response. :P I think it's fairly clear that changing the precedence of ! could lead to the problems I mentioned.

The change in precedence of bitwise operators would be less problematic, both because it's a less significant change relative to the precedence chart, and because the current precedence is counter-intuitive.

Besides the comparison operators, the precedence would also change when using bitwise operators with named unary operators. For example, rand $value & $mask is (rand $value) & $mask now, but would be rand($value & $mask) instead.

That sort of code probably wouldn't appear in production either -- I expect a programmer would use parentheses to make the precedence explicit -- but it does seem slightly more likely than the == and & case.

At first, it made sense to me to get the bit-wise operators finally grouped together and also get the logical operators finally grouped together. Plus, I'd been recently surprised by the rather tight binding of !.

But ! is also useful for extracting a Boolean value from a possibly-non-Boolean value. And since we don't have operators for "is logically equivalent" nor for "is not logically equivalent", it can be convenient to write, for example: if(  ! $expr == ! $cond  ) { Also, we do have negated versions of all of the comparison operators so there isn't much need for: if(  ! ( $value == $expr )  ) { So I realized that this change wasn't going to fly.

But the main point of my proposal was the bit-wise operators (hence the title). I snuck the change to ! into the table but didn't mention it anywhere. And now I'm sneaking it back out. q-: Sorry for the confusion.

It does make some (though not a lot of) sense to put ! in with the other unary operators.

        - tye (but my friends call me "Tye")