[cfe-dev] [PATCH] -Wconversion-null

[Joshua Cranmer]

On 3/15/2012 8:31 PM, James K. Lowden wrote:
> Why do people think Boolean operations are hard?  Why don't
> they get their knickers in a twist over !, too?  When I looked into it
> back then, I could find only two kinds of languages: those that define
> logical precedence and those that don't.  Of those that do, all bind AND
> before OR.
The only reason that this is the case is because and and or are 
equivalent to multiplication and plus in Boolean algebra. If you don't 
know this fact (or don't think about it), there really is no rationale 
for why it ought to be one way or the other. When I'm coding, I 
generally don't get thought to the underlying ring theory of computers, 
so it's not immediately evident to me why this ought to be the case. 
Face it, most people don't memorize the precedence charts and instantly 
plan for minimizing parenthesis usage, especially when you consider that 
precedence does vary between languages and not all programmers stick to 
one language their entire career.

Indeed, I would suppose most people have the following model of the 
operators, in decreasing order of precedence:
Postfix unary operators and call, array, arrow, dot operators.
Prefix unary operators
"Arithmetic operators" (note that + - are lower than * / %, as we have 
had beaten into us since grade school)
comparison operators (==, >, etc.)
logical operators (&&, ||)
ternary
assignment

Most programmers probably can't deduce the correct paranthesizations of 
the following operations:
a << b + c (although a << b | c is more likely to be guessed correctly)
flag & mask == mask (unless you've been bitten by this constantly 
before. Note that, e.g., python has a different answer than C/C++)
a & b ^ c | d (even if you rationalize why & has higher precedence than 
|, where does ^ go?)
*x.*ptr

The most logical reasoning for some of these instructions (the second 
and fourth in particular) turn out to be wrong (&/== and the different 
precedence of .*/->* and ./->), while the others don't have a strong, 
intuitive argument for any precedence over the other one. I should be 
able to look at code and not have to reason about the formal underlying 
algebraic model to figure out what the intent is, and I would rather 
have a compiler that is too quick to accuse my operations of not being 
what I intended than one which would stand by and let me commit code 
(and pass review) because the language's syntax is not intuitive.

Finally, note that language syntax can have irreparable bugs in this 
regard: the most famous example is PHP's incorrect associativity of ?: 
which makes a ? b : c ? d : e equal to (a ? b : c) ? d : e instead of 
the arguably more natural a ? b : (c ? d : e). So it may be correct 
according to the language specification, but that doesn't mean it is 
correct according to intuition.

-- 
Joshua Cranmer
News submodule owner
DXR coauthor