Is it too late to hope for D to get a *real* boolean type ?

That is, not the integer-compatible bit one that is "bool";
but a special-purpose "boolean" type, like the one Java has.
(accidently also present in C#, there under a name of bool)


I was hoping for the following code snippets to be illegal:

if (pointer)
if (a = b) // just a typo!
if (c = readchar())
i = true + 1;

Instead they could be replaced by the equivalent new code:

if (pointer != null)
if (a == b) // what was meant!
if ((c = readchar()) != 0)
i = (true ? 1 : 0) + 1;

The first block is C/C++, and the second block is Java/C#.


It seems like "true" and "false" has already been defined
as "bit", which I think is unfortunate. They should have
been "boolean". Better bit names would be "on" and "off".

Can it be added/changed, or are we stuck with C9X/C++ bool?

--anders


PS.
Aliasing "bit" to represent "bool" is perfectly fair.
It's even *better* than what my current GCC 3.4 does,
where sizeof(bool) == 4 ! (I'm guessing it uses "int")

Just that I had hoped for something that was better...
(since C source code compatibility is not an issue ?)
Or did Walter actively CHOOSE the old C style, for D ?

Anders F Björklund schrieb:
> Is it too late to hope for D to get a *real* boolean type ?

> I was hoping for the following code snippets to be illegal:
> 
> if (pointer)

Why should that be illegal? I find it very elegant at many cases. Many others also do.

> if (a = b) // just a typo!

Assignment in if statement is made illegal and will be rejected by the compiler.

> Instead they could be replaced by the equivalent new code:

> i = (true ? 1 : 0) + 1;

I don't see a reason why this here should be done.

> Can it be added/changed, or are we stuck with C9X/C++ bool?

In principle, it is not like anything couldn't be changed by a technical reason, we're not past 1.0 yet. However, such questions have already been discussed dozens, dozens of times with no consensus. Your message doesn't contribute much to the discussion because it fails to provide any argument as to why we should do that. The common typo you show is detected by the compiler. You didn't even check the code you post.

-eye

In article <ck1gtq$14r$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Is it too late to hope for D to get a *real* boolean type ?

Depends on what you're proposing.

>That is, not the integer-compatible bit one that is "bool"; but a special-purpose "boolean" type, like the one Java has. (accidently also present in C#, there under a name of bool)
>
>
>I was hoping for the following code snippets to be illegal:
>
>if (pointer)

Unlikely.  This is too important for C source compatibility.

>if (a = b) // just a typo!
>if (c = readchar())

These are already both illegal.

>i = true + 1;

Messy, but this is even legal in C/C++.

>Instead they could be replaced by the equivalent new code:
>
>if (pointer != null)

Arguably a good idea.

>if (a == b) // what was meant!
>if ((c = readchar()) != 0)

Already necessary.

>i = (true ? 1 : 0) + 1;

I like this too.

>The first block is C/C++, and the second block is Java/C#.
>
>
>It seems like "true" and "false" has already been defined as "bit", which I think is unfortunate. They should have been "boolean". Better bit names would be "on" and "off".
>
>Can it be added/changed, or are we stuck with C9X/C++ bool?

Until D is standardized, anything is possible.  But this is a religious issue that has been discussed to death.  If anything is likely to change Walter's mind about "bit" it's that implementing arrays and slicing and such turned out to be more complex than expected, and it may not be worth the trouble for what could also be implemented in a library class.

>PS.
>Aliasing "bit" to represent "bool" is perfectly fair.
>It's even *better* than what my current GCC 3.4 does,
>where sizeof(bool) == 4 ! (I'm guessing it uses "int")

I don't think the size of bool should matter, though it would be nice if it were always one byte (just for the sake of storage).  The C++ standard, however, doesn't place any storage requirements on bool, so 4 bytes is fair game.

>Just that I had hoped for something that was better...
>(since C source code compatibility is not an issue ?)
>Or did Walter actively CHOOSE the old C style, for D ?

C source code compatibility is an issue, to a degree.  Walter has tried to keep behavior consistent whenever doing so doesn't result in undesired behavior. It's what constitutes undesired behavior that's sometimes an issue of contention.


Sean

Ilya Minkov wrote:

> Why should that be illegal? I find it very elegant at many cases. Many others also do.

Because the type of variable "pointer" is not a boolean ?

This was after adding a new boolean core type to the language,
and then requiring that if(), while() etc. get boolean params.

>> if (a = b) // just a typo!
> 
> Assignment in if statement is made illegal and will be rejected by the compiler.

Great! (gcc catches it too, at least it issues a warning with -Wall:
"warning: suggest parentheses around assignment used as truth value")

>> i = (true ? 1 : 0) + 1;
> 
> I don't see a reason why this here should be done.

Again, because "boolean" and "int" are different types ?
(pros and cons have been discussed before, won't reiterate)

>> i = true + 1;

In C9X and C++, they both assign a value 2 to the i variable.
In Java and C#, they both issue a fatal compiler "type error".

> In principle, it is not like anything couldn't be changed by a technical reason, we're not past 1.0 yet. However, such questions have already been discussed dozens, dozens of times with no consensus. Your message doesn't contribute much to the discussion because it fails to provide any argument as to why we should do that. The common typo you show is detected by the compiler. You didn't even check the code you post.

I compiled the code now, and it did say:
'=' does not give a boolean result


I just wanted to point out that C(9X) and C++ chose one solution,
and that Java and C# chose another ? D currently sides with the
C side, just wanted to know if that was by choice or by accident ?

If there are no plans to add such a non-arithmetic type to D,
then I'm perfectly fine with the current ones: bit, 1 and 0 -
and their aliases: bool, true and false. I'm an old C user too.


I just thought that like strings and garbage collection, "boolean"
was a nice addition to C by Java, and hoped it would end up in D too...

But if C and C++ have gotten along without it, so could D, I guess ?
Just didn't see any strong statements that D would not ever add one...


Sorry for beating the poor old horse,
--anders

Sean Kelly wrote:
>>Aliasing "bit" to represent "bool" is perfectly fair.
>>It's even *better* than what my current GCC 3.4 does,
>>where sizeof(bool) == 4 ! (I'm guessing it uses "int")
> 
> I don't think the size of bool should matter, though it would be nice if it were
> always one byte (just for the sake of storage).  The C++ standard, however,
> doesn't place any storage requirements on bool, so 4 bytes is fair game.

Yeah, implementing a "bool" in C can be a bit tricky ?
Whether to choose "char" for size or "int" for speed...

"bit" is a lot easier. It's always 0.125 byte. :-)

--anders

On Wed, 06 Oct 2004 21:46:40 +0200, Ilya Minkov wrote:

> Anders F Björklund schrieb:
>> Is it too late to hope for D to get a *real* boolean type ?
> 
>> I was hoping for the following code snippets to be illegal:
>> 
>> if (pointer)
> 
> Why should that be illegal? I find it very elegant at many cases. Many others also do.

This syntax is just a shorthand for 'if (pointer != null)', but in conceptual terms the 'if' statement syntax should be more like ...

  IFSTMT :: 'if' '(' boolean_expression ')' statement_block [ 'else'
statement_block ]

In other words, the expression within the parenthesis should result in a boolean data value.

I take the following to be true even if C/C++/D et al disagree somewhat:
 ** Pointers are not booleans.
 ** Numbers are not booleans.
 ** Booleans are not numbers.

>> if (a = b) // just a typo!
> 
> Assignment in if statement is made illegal and will be rejected by the compiler.

It is odd maybe, that D decides to make this 'concession' but leaves other potential bug makers in place (eg fallthru in switch)

>> Instead they could be replaced by the equivalent new code:
> 
>> i = (true ? 1 : 0) + 1;
> 
> I don't see a reason why this here should be done.

Simple, booleans are not numbers so therefore one cannot do arithmetic on them. What do three truths and a falsehood add up to? It makes no sense does it? What one needs to do is to say, if we substitute each truth with 1 and each falsehood with 0, then 3*T + F = 3. The syntax above makes it clear to the reader of the code that such an arbitary substitution is being carried out. I say 'arbitary' because some systems believe that a truth should be substituted by -1.

>> Can it be added/changed, or are we stuck with C9X/C++ bool?
> 
> In principle, it is not like anything couldn't be changed by a technical reason, we're not past 1.0 yet. However, such questions have already been discussed dozens, dozens of times with no consensus. Your message doesn't contribute much to the discussion because it fails to provide any argument as to why we should do that. The common typo you show is detected by the compiler. You didn't even check the code you post.
> 
> -eye

I hope I've help to provide an "argument as to why we should do that".

-- 
Derek
Melbourne, Australia
7/10/2004 9:48:43 AM

In article <ck1gtq$14r$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Is it too late to hope for D to get a *real* boolean type ?
>
>That is, not the integer-compatible bit one that is "bool"; but a special-purpose "boolean" type, like the one Java has.

In my time on this forum, this has to qualify as /the/ most Frequently Asked Question we ever hear. Can't we just put it in the actual FAQ at http://www.digitalmars.com/d/faq.html and be done with it?

Q. Why doesn't D have a real boolean type?
A. Walter doesn't like it.

Arcane Jill

Arcane Jill wrote:

> In my time on this forum, this has to qualify as /the/ most Frequently Asked
> Question we ever hear. Can't we just put it in the actual FAQ at
> http://www.digitalmars.com/d/faq.html and be done with it?

I did see the *question* a lot, just not any answers... :-)
The discussion seemed more to be about the size of "bool" ?

> Q. Why doesn't D have a real boolean type?
> A. Walter doesn't like it.

OK, "bit" it is then... (With the "bool" syntactic sugar)
Just as how it usually works, in C/C++: "non-zero is true"

Too bad,
--anders

Derek Parnell wrote:
> I take the following to be true even if C/C++/D et al disagree somewhat:
>  ** Pointers are not booleans.  ** Numbers are not booleans.  ** Booleans are not numbers.

Actually, they all agree on: "there is no boolean"

"true" is a number, with the value 1.
"false" is a number, with the value 0.

"equals true" is the same as "is not zero"
"equals false" is the same as "equals zero".

And the recommended int type for storing is "bool".

--andeers

Arcane Jill wrote:

> In article <ck1gtq$14r$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>>
>>Is it too late to hope for D to get a *real* boolean type ?
>>
>>That is, not the integer-compatible bit one that is "bool"; but a special-purpose "boolean" type, like the one Java has.
> 
> In my time on this forum, this has to qualify as /the/ most Frequently Asked Question we ever hear. Can't we just put it in the actual FAQ at http://www.digitalmars.com/d/faq.html and be done with it?
> 
> Q. Why doesn't D have a real boolean type?
> A. Walter doesn't like it.
> 
> Arcane Jill

Putting it in the FAQ is fine but I assume you weren't serious about the answer "Walter doesn't like it". Walter must have some snippets scattered about with a better rationale.