Mehrdad:

> How do you deal with BOOL?

D typedef was meant for this. Until there is something (probably library-based) to replace it, there are structs with alias this.

Bye,
bearophile

On Sun, 19 Jun 2011 19:42:22 -0400, bearophile <bearophileHUGS@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

Am 20.06.2011 14:47, schrieb Steven Schveighoffer:
> On Sun, 19 Jun 2011 19:42:22 -0400, bearophile <bearophileHUGS@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.

Cheers,
- Daniel

On Mon, 20 Jun 2011 09:17:56 -0400, Daniel Gibson <metalcaedes@gmail.com> wrote:

> Am 20.06.2011 14:47, schrieb Steven Schveighoffer:
>> On Sun, 19 Jun 2011 19:42:22 -0400, bearophile
>> <bearophileHUGS@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.

-Steve

Am 20.06.2011 15:31, schrieb Steven Schveighoffer:
> On Mon, 20 Jun 2011 09:17:56 -0400, Daniel Gibson <metalcaedes@gmail.com> wrote:
> 
>> Am 20.06.2011 14:47, schrieb Steven Schveighoffer:
>>> On Sun, 19 Jun 2011 19:42:22 -0400, bearophile <bearophileHUGS@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++?

Cheers,
- Daniel

Steven Schveighoffer:

> 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?

I was thinking more about a warning than an error. But you are right, my enhancement request 5540 seems premature, I/we have to think some more about it.

Bye and sorry,
bearophile

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

> Am 20.06.2011 15:31, schrieb Steven Schveighoffer:
>> On Mon, 20 Jun 2011 09:17:56 -0400, Daniel Gibson
>> <metalcaedes@gmail.com> wrote:
>>
>>> Am 20.06.2011 14:47, schrieb Steven Schveighoffer:
>>>> On Sun, 19 Jun 2011 19:42:22 -0400, bearophile
>>>> <bearophileHUGS@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

Steven Schveighoffer:

> 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.

My enhancement request was about redundancies in the code, that sometimes hide implicit errors, they can't be 'near 100% invalid'. In this case I am not looking for explicit errors, some/many of the redundancies aren't bugs.

Bye,
bearophile

On Mon, 20 Jun 2011 11:10:58 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>
>> 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.
>
> My enhancement request was about redundancies in the code, that sometimes hide implicit errors, they can't be 'near 100% invalid'. In this case I am not looking for explicit errors, some/many of the redundancies aren't bugs.

What I'm saying is, if the compiler errors out when a good percentage of the cases are valid, it will become a nuisance error, and continually ignored/worked around.  We do not want nuisance errors.  Even if you make it a error only with -w, I think people will just stop using -w.  It needs to be:

a) almost always an error when it is encountered
b) very easily worked around, but with code that isn't common.

I think with the extra parentheses idea, b is satisfied, but a is not.  I can't say that there isn't a case where a is not satisfied by some specific criteria, but I haven't seen it yet.

-Steve