I would still say that is not ideal. If you do that, then you'll never going to learn rules like operator precedence. And neither the coworker reading the code. I thought that learning is a good thing. "Let's just put parentheses and never check the truth, not even of curiosity. 
" I admit this whole thing is a debate. So maybe there is no really right or wrong answer. But you may be completely right. For certain people, putting parentheses is the most appropriate choice.
I agree. Moreover -- superfluous parentheses are confusing. The reader will have to stop and think: why did they put parentheses here? Oh, no reason, I see.
I would actually like a warning for superfluous parentheses, not sure if there is a clippy lint for this.
2 Likes
Utterly perfect! You do realize that bit is ignored here (except if it's too big and overflow happens). Still want to insist there are no problem with these precendeces?
You'll never learn them except if you use them every day. It just so happen that I worked with bitmasks on my $DAYJOB for last few months thus illigiality of << precedence is still fresh in my mind. Othervise pretty knowledgeable @tczajka haven't done that recently thus he forgot. Even if I'm pretty sure he was bitten by it at some point in the past, but these things tend to be forgotten over time.
Unfortunately that's something people have very hard time agreeing about. You couldn't please everyone. And it's not clear how to trigger warning in your example while still trying to keen number of parenthesis to minimum.
The only clear case are parenthesis after if where they are never needed.
Other places… I'm not so sure about.
1 Like
Yeah, there's the #[warn(unused_parens)] lint which is enabled by default.
Your example demonstrates that bit is not ignored, it correctly prints different answers for different bits.
1 Like
Ugh. It's only ignored in C, but not in Rust. That one is on me, I guess, I still have to deal with C/C++ thus I never realized that Rust fixed that particular wart of C/C++.
That's nice, I guess, one less wart to keep in mind… when C/C++ would become history, means in half-century, I guess.
1 Like
This only warns about superfluous parentheses around the whole expression in certain cases, but what I want is a warning for superfluous parentheses where they don't change precedence, for example:
let x = a + (b * c);
let y = (a && b) || (c && d);
As no one has mentioned; I expect you know; the operators are not mathematical. You can write far worse just exploiting them being lazy boolean operators than a failure to understand precedence.
Agreed. ISTR Java has eleven levels of precedence, not sure offhand how many Rust has.
The reason I don't like over-reliance on the precedence table is that
- it's faster to put in parentheses --- I have not seen Rust complain about parentheses that (merely) clarify precedence --- than to poke around the precedence table
- if I'm looking at code because it doesn't work (and it's not written by me, recently), one of my doubts could well be whether the author knew the precedence table as well as they thought they did. Or, they did, but changed the code in a hurry and slipped up. Parentheses save time here since they clarify the intent, saving time in what might be a stressful repair situation.
This is very much intentional from rustc. It'll complain about things like *(*b) but in general if there's potential precedence confusion about something it's perfectly happy for you to clarify with parens, even if they're not strictly necessary.
(TBH I wish parens were required in more places. There's lots of mixings of different kinds of operators that I think should just straight-up not work without parens.)
No, it is not ignored.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.