On Saturday, 27 April 2013 at 20:31:15 UTC, Mehrdad wrote:
> The problem is 'bool' has *NOTHING* in common with integers!
>
> - Can't use + - * / << >> on bool's

Because currently D views booleans as a 1 bit int, you can do seemingly nonsensical things with the bool type

bool b = false + true; // OK
bool b = true * true; // OK
bool b = true / true; // OK
bool b = true + true; // compile error because 2 does not fit into 1 bit.

Even if you accept the view that bool is a 1 bit int, this conditional makes no sense at all

int x = -123456;
if (x) then
{
   // evaluates to true, but why???
}

if (x == true) then
{
   // false because x != true(1), even though previously it was true
}

If bools are 1 bit ints, then why do we have 'true' and 'false' as keywords? Those keywords only serve to confuse the programmer into thinking that the bool type is actually a real boolean type.

The worse thing about this situation is the inconsistencies. It would not be nearly as bad if bool really was a 1 bit int type, instead it sometimes behaves like an int and sometimes it behaves like a boolean. Why name name the type "bool" instead of "bit"? Why have true and false keywords?

What I gather from the state of affairs, is an attempt to create the illusion of a boolean while retaining all of the properties of a 1 bit int type, with the notable exception of the weird conditional that evaluates an integer to true if it is not 0.

--rt

On Saturday, 27 April 2013 at 19:51:48 UTC, Walter Bright wrote:
> An analogous issue comes up here now and then about 'char' and characters. Are chars an 8 byte integer, or are they characters, or are they octets, or should access only be allowed to multibyte characters as an indivisible code point? (This comes up in regards to indexing char[].)

The real problem I think is caused by trying to fit two conceptually different things into the same container and then merging the two conceptually different behaviors together. It's very confusing and causes unexpected conflicts.

My analogy is having two exactly identical containers labeled "water", but use one to store water and the other gasoline, then wait until someone yells "fire!".

To solve the char problem, what should be done, is have a real 'char' type and a real 'byte' type to settle the matter, and use explicit casting where required.

To transform bool into something sensible that we can all agree with, there should a a 'bool' type and a 'bit' type, and use explicit casting where required.

What we have instead is a confounding merging of dissimilar containers for  conflicting purposes. This is completely avoidable and easily so.

--rt

VRP is only useful when doing this:

short s = 1000; // 1000 is int, but it's safe to put it into a short

Integers are not booleans. I agree with the others that bool being treated as an int is an implementation detail derived from C.

Or are you just bored for doing:
if( x == 0 )

instead of
if( x )

?

On 4/27/2013 2:29 PM, Rob T wrote:
> If bools are 1 bit ints, then why do we have 'true' and 'false' as keywords?

Because writing cast(bool)0 and cast(bool)1 is unappealing.

On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright wrote:
> On 4/27/2013 2:29 PM, Rob T wrote:
>> If bools are 1 bit ints, then why do we have 'true' and 'false' as keywords?
>
> Because writing cast(bool)0 and cast(bool)1 is unappealing.

I would expect boolean literals to be something like 0b and 1b, not true and false then.

On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright wrote:
> On 4/27/2013 2:29 PM, Rob T wrote:
> Because writing cast(bool)0 and cast(bool)1 is unappealing.

why need to write that? just drop the bool type entirely and go ahead with an integer that you interpret as a boolean.

welcome back to C (k&r).

On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright wrote:
> On 4/27/2013 2:29 PM, Rob T wrote:
>> If bools are 1 bit ints, then why do we have 'true' and 'false' as keywords?
>
> Because writing cast(bool)0 and cast(bool)1 is unappealing.


Unappealing to whom?

On Saturday, 27 April 2013 at 21:59:50 UTC, eles wrote:
> On Saturday, 27 April 2013 at 21:52:30 UTC, Walter Bright wrote:
>> On 4/27/2013 2:29 PM, Rob T wrote:
>> Because writing cast(bool)0 and cast(bool)1 is unappealing.
>
> why need to write that? just drop the bool type entirely and go ahead with an integer that you interpret as a boolean.

The problem is that Walter appears to want the convenience of a real bool type, but also the convenience of a real bit type, all merged together into one container that is confusingly labeled as 'bool'.

See my previous post about the problems caused when merging two conceptually different things into one container and then make it appear as if it stores only one of the conceptually different things - sometimes. Thats never a good idea.

We can solve the problem by defining a real boolean type and a real bit type and allow explicit casting if required (which should be rare).

--rt

Am 27.04.2013 23:52, schrieb Walter Bright:
> On 4/27/2013 2:29 PM, Rob T wrote:
>> If bools are 1 bit ints, then why do we have 'true' and 'false' as
>> keywords?
>
> Because writing cast(bool)0 and cast(bool)1 is unappealing.
>

No, this brings us back into the realm of C and weak type checking.

> If bools are 1 bit ints, then why do we have 'true' and 'false' as keywords? Those keywords only serve to confuse the programmer into thinking that the bool type is actually a real boolean type.

C++ has also true and false and they are converted to integers by the compiler.