-Wparentheses lumps too much together

[jklowden@freetds.org]

Hello Gentlemen, 

Much as I'm a fan of the GCC and rely on -Wall, I would like to suggest 
to you that -Wparentheses should be split up, and things it checks/suggests
be moved out of -Wall.  If this is not the right forum or if you'd rather
see this as a bug report, I'm happy to go where I'm pointed.  

The basic problem with this warning is that it includes some helpful advice 
about some subtle bugs with some "dear beginner" advice about "operators ...
whose precedence people often get confused about."  

My assertion is that operator precedence is fundamental to C.  No one can 
read C without knowing.  If you're unsure about precedence, you're only 
guessing.  Moreover, to interpret operator precedence, it's not necessary
to, say, rememember the variables' declarations 100 lines earlier and 
it's impossible to be misled by non-syntactic indentation.  Everything you
need to know to understand the statement is contained in the statement 
itself.  

My specific candidate for exclusion from -Wall is this one:

	if (a && b || c && d)

which yields (as you know) advice to parenthesize the two && pairs.  

I very much think this is unhelpful, counterproductive advice.
Yes, I know beginners get confused by and/or precedence.  But
*every* language that I know of that has operator precedence places
'and' before 'or'.  More important, a C programmer will encounter
many thousands such expressions in his dealings with the language.
To "help" him is merely to retard his education.

But -Wall isn't really concerned with helping beginners, right?  It's really 
about avoiding errors and pitfalls.  That's why I suggest this and other
precedence warnings be moved to -Woperator (notional).  If you need help 
learning C, GCC will help you.  But if you're maintaining 100,000 lines of 
portable, standards-compliant C (as I do), you don't want warnings to 
parenthesize things that don't need it.  

At the risk of overstaying my welcome, let me answer the commonest reply, 
"what's a few parentheses among friends?"  The problem is that, for the 
experienced programmer, "extra" parenthesis are a signal: something 
unusual is going on here.  By forcing your most careful users --
those who bother with -Wall -- to use parenthesis to enforce what the compiler
would do anyway where the meaning was clear(er) without them, you're 
removing a signalling tool by "insisting" on white noise.  I don't think 
that's a good outcome and I doubt it was the intention, but there it is.  

By the way, I distinguish the 'and/or' advice from the more helpful concern:

	while ((erc=foo()) != 0)

because there the programmer's intent is likely impossible to express 
without parentheses; the idiom requires the override.  

One last point.  In looking for the rationale behind this warning, I searched
for examples of it.  I didn't find any discussion on this list.  What I did
find were many examples of people rototilling perfectly fine code, "improving"
it by adding unneeded parenthesis specifically so that it would compile 
cleanly with -Wall.  I think that's a shame: a waste of effort at best.  

I ask you, please, to consider splitting advice about operator precedence from
advice about mismatched if/else branches, and to exclude advice about 
making sure && is parenthesized ahead of || from -Wall.  -Wall is the 
standard for "good, clean code" in many projects.  This warning doesn't 
belong there.  

Thank you for your time and consideration.  

Regards, 

--jkl