One of the most intriguing novel ideas in Carbon (One of the "C++ Replacement languages" announced in 2022) is the idea that operator precedence should not be a total order.
Lots of prior languages have tried either:
1. No operator precedence, expressions must use parentheses so that it's very clear
2. No operator precedence, everything just happens left to right regardless
But Carbon says what if we do have precedence, but only between operators which programmers expect to have precedence - whenever it's unclear what should happen the compiler instead rejects that, the same way many languages won't let you ask whether 5 == "Five" because you need to explain WTF you intended as most likely you've screwed up and didn't realise they're completely different types.
WGSL (the shading language for WebGPU) has something similar[1].
For example, `a + b << c` will fail to parse in a conforming implementation, as will `a << b << c` and `a && b || c`. Note however that `a && b && c` does parse. I find these rules to be well-thought through.
SmallTalk has the left-to-right for everything principle because everything is message passing and "operators" are just binary (as in two argument) messages which catches many out.
2 - 1 * 5
will return 5, while many would expect -3. You must apply parentheses if you want a precedence other than ltr.
Lots of prior languages have tried either:
1. No operator precedence, expressions must use parentheses so that it's very clear
2. No operator precedence, everything just happens left to right regardless
But Carbon says what if we do have precedence, but only between operators which programmers expect to have precedence - whenever it's unclear what should happen the compiler instead rejects that, the same way many languages won't let you ask whether 5 == "Five" because you need to explain WTF you intended as most likely you've screwed up and didn't realise they're completely different types.