Would it be useful if the compiler saw '<expression> == true' as '<expression> != 0'?

Then these would be equivalent ...

   if (Fld) ...

and

   if (Fld == true) ...

because currently these are not equivalent.

import std.stdio;
int main()
{
    int A = 2;

    if (A) writefln("A");
    if (A!=0) writefln("A!=0");
    if (A==true) writefln("A==true");

    return 0;
}

-- 
Derek Parnell
Melbourne, Australia
31/08/2005 9:43:47 PM

"Derek Parnell" <derek@psych.ward> wrote in message news:jag0mz602hw$.u59i5vti46wf$.dlg@40tude.net...
> Would it be useful if the compiler saw '<expression> == true' as '<expression> != 0'?
>
> Then these would be equivalent ...
>
>   if (Fld) ...
>
> and
>
>   if (Fld == true) ...
>
> because currently these are not equivalent.

I'm not sure if you're looking for utility or for syntactic sugar ;)

The problem with that is that 'true' would no longer just be a simple constant.  It would be a constant some of the times (like func(5,true)), but other times (when comparing), it would be something entirely different.  It wouldn't have a value; it'd be something of a construct in and of itself. Or rather, '==true' would be a construct, as without the '==', it wouldn't work the same way.

On Wed, 31 Aug 2005 08:58:07 -0400, Jarrett Billingsley wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:jag0mz602hw$.u59i5vti46wf$.dlg@40tude.net...
>> Would it be useful if the compiler saw '<expression> == true' as '<expression> != 0'?
>>
>> Then these would be equivalent ...
>>
>>   if (Fld) ...
>>
>> and
>>
>>   if (Fld == true) ...
>>
>> because currently these are not equivalent.
> 
> I'm not sure if you're looking for utility or for syntactic sugar ;)
> 
> The problem with that is that 'true' would no longer just be a simple constant.  It would be a constant some of the times (like func(5,true)), but other times (when comparing), it would be something entirely different.  It wouldn't have a value; it'd be something of a construct in and of itself. Or rather, '==true' would be a construct, as without the '==', it wouldn't work the same way.

Umm, yeah ... so where's the problem?

When people write "if (X == true)" I assume they want to know if X contains one of the many values that D regards as a truth value. If they want to see if X contains the value 1, they would write "if (X == 1)". So in this regards, the syntax "EXPR == true" *is* a construct.

Why I even raised this is that I tripped over this today ...

  if (isalpha(X) == true)

as it was only 'working' for upper case alphas. Lowercase alphas returned 2 and not 1. This is because isalpha is defined as

int isalpha(dchar c)  { return (c <= 0x7F) ? _ctype[c] & (_ALP) : 0; }

where _ALP has the value 3. My assumption was that functions named "is..." would return a true/false value (yeah, I know ... RTFM; but what manual?).

In other words I assumed it was coded as ...

bool isalpha(dchar c){return (c<=0x7F)&&(_ctype[c]&(_ALP)) ? true:false);}

My bad I know, but then I got to thinking that I wish the compiler could recognize the HINT that I was after truth and not a numeric comparison.

-- 
Derek Parnell
Melbourne, Australia
31/08/2005 11:15:56 PM

In article <jag0mz602hw$.u59i5vti46wf$.dlg@40tude.net>, Derek Parnell says...
>
>Would it be useful if the compiler saw '<expression> == true' as '<expression> != 0'?
>
>Then these would be equivalent ...
>
>   if (Fld) ...
>
>and
>
>   if (Fld == true) ...
>
>because currently these are not equivalent.
>
>import std.stdio;
>int main()
>{
>    int A = 2;
>
>    if (A) writefln("A");
>    if (A!=0) writefln("A!=0");
>    if (A==true) writefln("A==true");
>
>    return 0;
>}


Is truth the complement of falsehood?   Who defines truth as anything which is not false?

-Sha

"Derek Parnell" <derek@psych.ward> wrote in message news:jag0mz602hw$.u59i5vti46wf$.dlg@40tude.net...
> Would it be useful if the compiler saw '<expression> == true' as '<expression> != 0'?

Or one could change the implicit conversion rules "usual arithmetic conversions" described on http://www.digitalmars.com/d/type.html to say that if one of the two types is "bit" that the other type is converted to bit. This would be rule 4a - between the float conversions and the integer promotions. Then <expr> == true would have the behavior you expect.

On Wed, 31 Aug 2005 14:46:29 -0400, Ben Hinkle wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:jag0mz602hw$.u59i5vti46wf$.dlg@40tude.net...
>> Would it be useful if the compiler saw '<expression> == true' as '<expression> != 0'?
> 
> Or one could change the implicit conversion rules "usual arithmetic conversions" described on http://www.digitalmars.com/d/type.html to say that if one of the two types is "bit" that the other type is converted to bit. This would be rule 4a - between the float conversions and the integer promotions. Then <expr> == true would have the behavior you expect.

Yep, that would do it too.

-- 
Derek Parnell
Melbourne, Australia
1/09/2005 7:30:06 AM

On Wed, 31 Aug 2005 14:13:42 +0000 (UTC), Shammah Chancellor wrote:

> In article <jag0mz602hw$.u59i5vti46wf$.dlg@40tude.net>, Derek Parnell says...
>>
>>Would it be useful if the compiler saw '<expression> == true' as '<expression> != 0'?

[snip]

> Is truth the complement of falsehood?   Who defines truth as anything which is not false?

Ummm... me?  I kinda feel that an assertion is either true or false but not both at the same time. It cannot be neither, although we may not know which it is at any given instant.  But now we getting all philosophical and off topic ;-)

-- 
Derek Parnell
Melbourne, Australia
1/09/2005 7:30:44 AM

Derek Parnell wrote:
> Would it be useful if the compiler saw '<expression> == true' as
> '<expression> != 0'? 
> 
I saw your isAlpha() snippet and I do agree that is quite a language problem! However your alternative is incorrect just as that, as it is incomplete: one has to consider the general case of '<int/long expression> == <bool expression>' (and vice-versa), not just with true. For instance as in this:
  ( isAlpha('c') == returnsTrue() )

So, as for '<int/long expression> == <bool expression>', in my opinion, it should either work as you expect (do a boolean compare), or it should be illegal (compile error). That isAlpha() bug was really nasty!


-- 
Bruno Medeiros
Computer Science/Engineering student

In article <1vyjlspt3ayjp.i722adx36thy.dlg@40tude.net>, Derek Parnell says...
>
>On Wed, 31 Aug 2005 14:13:42 +0000 (UTC), Shammah Chancellor wrote:
>
>> Is truth the complement of falsehood?   Who defines truth as anything which is not false?
>
>Ummm... me?  I kinda feel that an assertion is either true or false but not both at the same time. It cannot be neither, although we may not know which it is at any given instant.  But now we getting all philosophical and off topic ;-)

Quantum states make things even more intersting ;-)  The answer to this seems to go back to the old argument about whether bit is a numeric or logical type.  If bit is numeric then current behavior makes perfect sense, but the constants 'true' and 'false' are quite misleading.  Otherwise, I agree that the behavior must change.


Sean

In article <1xfwna3ygghr4.vv7m5z2cm8rt.dlg@40tude.net>, Derek Parnell says...
>
>On Wed, 31 Aug 2005 14:46:29 -0400, Ben Hinkle wrote:
>
>> "Derek Parnell" <derek@psych.ward> wrote in message news:jag0mz602hw$.u59i5vti46wf$.dlg@40tude.net...
>>> Would it be useful if the compiler saw '<expression> == true' as '<expression> != 0'?
>> 
>> Or one could change the implicit conversion rules "usual arithmetic conversions" described on http://www.digitalmars.com/d/type.html to say that if one of the two types is "bit" that the other type is converted to bit. This would be rule 4a - between the float conversions and the integer promotions. Then <expr> == true would have the behavior you expect.
>
>Yep, that would do it too.


This is rediculous.  Bit should be consistent with int and any other numeric
type.  Bool should be a
separate type as another thread was stating.  Converting any other type to bit
when the number is
greater than 1 would not result in the expected behavior, but instead an
overflow. It should throw an
exception.

Why would a comparision for bit demote the larger type? Everywhere else where
numbers are promoted!
(To prevent overflows when comparing long to int!)

-Sha