Partial Operator Precedence

sheept 6 hours ago|

JavaScript does something similar for the exponentiation operator. This is a syntax error:

    -a ** b

Someone who learned PEMDAS in school may argue it should be equivalent to -(a * b), while a programmer may be used to unary operators binding tightest, so (-a) * b.

boxed 6 hours ago||

I like the compromise, although I still think operator precedence in itself is evil :P Lisp kinda made the right call by mistake.

jraph 6 hours ago||

Made the right call, yes, but at the right time and with the right parameters above all!

tgv 5 hours ago||

So did Forth, but that's no guarantee for readability. APL got the worst of both worlds, IMO.

IshKebab 5 hours ago|

This is very clearly the best design for operator precedence IMO and it's nice that Zig has converged on it. It would be good to get it as a linting/formatting rule in Rust too (maybe that already exists?).

kibwen 36 minutes ago|

> It would be good to get it as a linting/formatting rule in Rust too (maybe that already exists?).

Yes, Clippy has a "precedence" lint that's enabled by default: https://clippy.rust-lang.org/master/index.html?search=preced...

Here's what it looks like:

    warning: operator precedence might not be obvious
     --> src/main.rs:2:5
      |
    2 |     1 << 2 + 3;
      |     ^^^^^^^^^^ help: consider parenthesizing your expression: `1 << (2 + 3)`
      |
      = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.99.0/index.html#precedence
      = note: `#[warn(clippy::precedence)]` on by default