Yet another slap on the hand by implicit bool to int conversions

[Steven Schveighoffer]

On Mon, 20 Jun 2011 09:42:45 -0400, Daniel Gibson <metalcaedes at gmail.com>  
wrote:

> Am 20.06.2011 15:31, schrieb Steven Schveighoffer:
>> On Mon, 20 Jun 2011 09:17:56 -0400, Daniel Gibson
>> <metalcaedes at gmail.com> wrote:
>>
>>> Am 20.06.2011 14:47, schrieb Steven Schveighoffer:
>>>> On Sun, 19 Jun 2011 19:42:22 -0400, bearophile
>>>> <bearophileHUGS at lycos.com> wrote:
>>>>
>>>>> Timon Gehr:
>>>>>
>>>>>> Maybe DMD could warn on nonsense of the form x != x.
>>>>>
>>>>> Right. This thread is very good food for this enhancement request of
>>>>> mine:
>>>>> http://d.puremagic.com/issues/show_bug.cgi?id=5540
>>>>>
>>>>> Vote for this enhancement :-)
>>>>
>>>> I don't think this is a good idea.  Generic code could result in an
>>>> error where there shouldn't be.  For example:
>>>>
>>>> int foo(T)()
>>>> {
>>>>    if(T.sizeof == char.sizeof)
>>>>      ...
>>>> }
>>>>
>>>> Would this fail to compile where T == char?  What about if T == ubyte?
>>>>
>>>> Generic programming sometimes results in silly code that is perfectly
>>>> acceptable as generic code, and we need to take this into account  
>>>> before
>>>> making decisions assuming a person is writing the code.
>>>>
>>>> -Steve
>>>
>>> It probably makes more sense to use static if in that case - and static
>>> if could be an exception for these rules.
>>
>> static if has different semantics than if (it doesn't create a scope),
>> so maybe I want to use if.  But even so, static if is just as likely to
>> contain these bugs as a normal if.  Both use an expression to determine
>> whether the if should run or not, and there are quite a few constructs
>> that can be used in a static if expression.
>>
>
> Disallowing some things in if that are allowed in static if at least
> catch most bugs of this kind because normal if is more common.
>
> Maybe, as an alternative, "nonsensical" expressions could be allowed if
> template parameters are involved. Don't know how hard it is to implement
> this, though.
>
> Another alternative: nonsensical expressions need to be enclosed by an
> extra pair of parenthesis.
> I think I have seen this for cases like if( (x=foo()) ) {}, meaning if(
> foo() != 0), but x is assigned that value at the same time (so you could
> as well write "if( (x=foo()) != 0)", but I don't remember in what
> language (D doesn't allow it). Maybe it was a warning of g++?

Another point, let's say you know the size of an int is 4.  And you write  
something like:

if(read(stream, ptr, int.sizeof == 4))

where you meant to write:

if(read(stream, ptr, int.sizeof) == 4)

How can the compiler "catch" this?  It's the equivalent of int.sizeof ==  
int.sizeof, but it's not exactly written that way.

Another example:

if(read(stream, &x, x.sizeof == int.sizeof)) // x is of type int

It just seems too arbitrary to me to say exact_expression ==  
exact_expression is invalid.  It doesn't solve all the cases where you  
mistype something, and it can throw errors that are nuisances.

In order to have a fix for something like this, you need the error to be  
near 100% invalid.  Like nobody ever writes this as *valid* code:

if(cond);

no matter what cond is.

-Steve