I really don't wish to open up the old Bool wounds, but the following should surely be considered a bug.

~~~~~~~~~~~~~~
module foo;

bool x, y;


bool test ()
{
        return x == y;
}

bool test1 ()
{
        return x == false;
}

bool test2 ()
{
        return y is true;
}
~~~~~~~~~~~~~~

Compiled with -w, we get the following:

warning - foo.d(8): implicit conversion of expression (cast(int)(x) ==
cast(int)(y)) of type int to bit can cause loss of data
warning - foo.d(13): implicit conversion of expression (cast(int)(x) == 0)
of type int to bit can cause loss of data
warning - foo.d(18): implicit conversion of expression (cast(int)(y) is 1)
of type int to bit can cause loss of data


This is just plain daft. And it's just the kind of thing to contribute to a perception that D is "unpolished" and "unprofessional".



To eliminate such warnings (which one should strive to do), one has to resort to comedy:

~~~~~~~~~~~~~~
module foo;

bool x, y;


bool test ()
{
        return cast(bool) (x == y);
}

bool test1 ()
{
        return cast(bool) (x == false);
}

bool test2 ()
{
        return cast(bool) (y is true);
}
~~~~~~~~~~~~~~

That is: cast boolean expressions, using only boolean operands, to boolean expressions.

On Sat, 31 Dec 2005 10:16:04 +1100, Kris <fu@bar.com> wrote:

> I really don't wish to open up the old Bool wounds, but the following should
> surely be considered a bug.

> That is: cast boolean expressions, using only boolean operands, to boolean
> expressions.


Doesn't this happen because comparision expressions return an int rather than a bool (aka bit)? I'm sure this is done for performance reasons rather than good language reasons. Another trade off for those who prefer speed over clarity.

-- 
Derek Parnell
Melbourne, Australia

Kris wrote:
//smart and valid comments/questions removed

Oh Kris, what could it be that makes you think that boolean expressions should be of boolean type. What a strange idea. :)

Siriusly: It would be the best present for new year if Walter just simply added boolean type to D without touching bit.

Derek Parnell wrote:
> On Sat, 31 Dec 2005 10:16:04 +1100, Kris <fu@bar.com> wrote:
> 
>> I really don't wish to open up the old Bool wounds, but the following  should
>> surely be considered a bug.
> 
> 
>> That is: cast boolean expressions, using only boolean operands, to  boolean
>> expressions.
> 
> 
> 
> Doesn't this happen because comparision expressions return an int rather  than a bool (aka bit)? I'm sure this is done for performance reasons  rather than good language reasons. Another trade off for those who prefer  speed over clarity.
> 

No performance would be lost and clarity would be increased if int sized real boolean type would be added having nothing in common with bit.

On Sat, 31 Dec 2005 10:28:52 +1100, Ivan Senji <ivan.senji_REMOVE_@_THIS__gmail.com> wrote:

> Derek Parnell wrote:
>> On Sat, 31 Dec 2005 10:16:04 +1100, Kris <fu@bar.com> wrote:
>>
>>> I really don't wish to open up the old Bool wounds, but the following  should
>>> surely be considered a bug.
>>
>>> That is: cast boolean expressions, using only boolean operands, to  boolean
>>> expressions.
>>    Doesn't this happen because comparision expressions return an int rather  than a bool (aka bit)? I'm sure this is done for performance reasons  rather than good language reasons. Another trade off for those who prefer  speed over clarity.
>>
>
> No performance would be lost and clarity would be increased if int sized real boolean type would be added having nothing in common with bit.

Agreed. It's the "alias bit bool" that is the problem here. If bool was an int then this wouldn't happen so long as the compiler treated all non-zero values of a bool to mean 'true' and only used zero value to mean 'false'.

-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:

[...]
> If bool was an  int then this wouldn't happen so long as the compiler treated all non-zero  values of a bool to mean 'true' and only used zero value to mean 'false'.

... until someone comes up with a posting saying like:


Look at:

code:
bool x, y;
// some code omitted
writefln( x, y, x & y);

output:
truetruefalse

How comes? This surely must be a bug.

-manfred