bit shift operator precedence

[JeffBezanson]

Scrutinizing the operator precedence table, it struck me as a bit odd that bit shift operators have their own precedence level, strictly lower than multiplication. a*b>>c*d is an ugly expression to be sure, but it's parsed as (a*b)>>(c*d), which doesn't make a whole lot of sense.

Since a<<b means a*2^b, << should perhaps have the same precedence as *, or maybe even the same precedence as ^. Or maybe it should be moved to one notch higher than *, instead of one notch lower (putting it between * and //).

[sbromberger]

Reference table here: https://en.wikipedia.org/wiki/Order_of_operations#Programming_languages

Bitwise shift left and right is level 5, above ("lower than", technically) + / -.

See also http://www.knosof.co.uk/cbook/accu06a.pdf

[JeffBezanson]

Giving << lower precedence than + is widely regarded as a mistake.

The linked study looks interesting but I didn't manage to extract a concrete recommendation at a glance. Do you have a strong take-away from it?

[sbromberger]

Do you have a strong take-away from it?

None at all. I knew Ritchie never liked the precedence of bitwise operators in C; I wasn't suggesting that we emulate them. I was just providing a couple of reference points for the decision :)

[StefanKarpinski]

I wonder if we could do better with precedence in general by borrowing the idea from Fortress of making precedence a partial ordering and having it be an error not to parenthesize ambiguous cases.

[jakebolewski]

Wouldn't you still have to define a relative ordering of operators? I don't see how that proposal is that much better than having fixed rules with a couple ambiguous cases in terms of precedence level.

[mikewl]

I do feel while erroring or at least warning on potentially ambiguous statements would be nice. It seems though like something a linter could deal with instead.

[JeffreySarnoff]

I prefer bit ops binding more tightly than arith ops, and, subordinately, unary ops binding more tightly than binary ops.

[JeffreySarnoff]

Clarification:

   unary ops  before binary ops of the same nature
   bitwise logical ops { &, |, $, ↑  }  before arith ops { +, -, *, /, \, %, ^}
   arith ops before wordwise ops { >>, <<. >>>, ror, rol }
   wordwise ops before  comparatives { < .. == .. > } 
   comparatives before truth functional connectives { &&, ||, $$, ↑↑ }

[JeffBezanson]

Proposal: move bit shifts one notch higher than //, so x//1<<n is parsed as x//(1<<n). Triage feels it's better for shifts to be either strictly higher or strictly lower than arithmetic operators, instead of in the middle. It also seems weird to shift the result of a division; more useful to divide the result of a shift.

It's also possible shifts should be merged into the ^ level, since it behaves similarly.