## digitalmars.D.announce - DMD 0.148 release

• Walter Bright (3/3) Feb 25 2006 Lots of new stuff, I added new threads for them in the digitalmars.D
• Derek Parnell (27/29) Feb 25 2006 Well you almost got bool right Everything except that it does implic...
• Tom (7/11) Feb 25 2006 Sorry, how is the above different than the next?
• Derek Parnell (6/18) Feb 25 2006 No it wouldn't either. I rushed my response as I was going out visiting ...
• Tom (4/25) Feb 26 2006 That's ok, i see. :-) Wish your dad a happy birthday.
• Wang Zhen (5/39) Feb 25 2006 Pardon my ignorance, but why does D need a primitive type for booleans
• Kyle Furlong (3/46) Feb 25 2006 Because there exists a boolean type that has different contstraints than...
• Derek Parnell (24/39) Feb 25 2006 The short answer is that booleans are not numbers. They represent truth ...
• bobef (24/32) Feb 26 2006 Just thoughts...
• Derek Parnell (23/56) Feb 26 2006 Not so. It is possible to create 'calculations' using purely logic
• bobef (10/13) Feb 26 2006 I think this is the case. In programming when one says bool, he actually...
• Georg Wrede (18/21) Feb 26 2006 So am I.
• Kyle Furlong (3/33) Feb 26 2006 How would having a builtin, "purist" boolean type preclude using integer...
• Tom (8/41) Feb 26 2006 I'd like to hear the answer :) .
• Wang Zhen (4/52) Feb 26 2006 I'm curious to know how you can tolerate the much impure int and real
• Derek Parnell (8/11) Feb 26 2006 'int' is not impure. It is a defined subset of integers.
• Kyle Furlong (2/18) Feb 26 2006 This is what happens when the theorists collide with the hobbyists. ;(
• Ivan Senji (4/7) Feb 26 2006 A superset? Hmmm, integer bool has nothing to do with true booleans.
• Tom (5/57) Feb 26 2006 I think people learns to tolerate things. It's just a matter of time. An...
• Tom (7/66) Feb 26 2006 Sorry didn't understand before (part because of english not being my "ho...
• Georg Wrede (15/63) Feb 26 2006 Well, then we could skip the logical operators, right? No more && or ||....
• Kyle Furlong (5/78) Feb 26 2006 I'm wracking my brain for any reason why this statement is even remotely...
• Derek Parnell (21/34) Feb 26 2006 Firstly, I'm not saying that booleans are 0 or 1 - they are not even
• Georg Wrede (6/16) Feb 26 2006 Oh. I'm sorry. I'll try not to mention VB in the future.
• Ivan Senji (12/38) Feb 26 2006 Ok, I'll give an example of that right after you give an example of why
• Georg Wrede (15/60) Feb 26 2006 That's why we do want to have booleans. The whole point of having
• Ivan Senji (12/87) Feb 26 2006 Could it be that I missunderstood you? By your kind of booleans did you
• Georg Wrede (16/109) Feb 26 2006 No problem. The way this whole thread is going, half the time everybody
• Tom (5/114) Feb 26 2006 Really I can't see yet why you don't like the pure bool. We should see a...
• Georg Wrede (7/32) Feb 26 2006 In this post alone, there's a half dozen references to "my kind of bool"...
• Ivan Senji (19/54) Feb 26 2006 I agree completly that on the inside they should be ints for some
• Tom (4/4) Feb 26 2006 [snip]
• Walter Bright (5/9) Feb 26 2006 Why? This is a practice I got into with C/C++, and I did it because 1 ca...
• Ivan Senji (10/24) Feb 26 2006 The reason should be obvious. While(condition). Condition should be
• Roberto Mariottini (21/39) Feb 27 2006 One of my students once had code written like this:
• Walter Bright (8/20) Feb 27 2006 1 isn't type safe??
• Derek Parnell (13/38) Feb 27 2006 Agreed that the 'while(1)' idiom is not going anywhere, but Walter, whic...
• Walter Bright (12/18) Feb 28 2006 They are both equivalent. There is no technical, usability, portability,...
• Bruno Medeiros (11/30) Feb 28 2006 As for the usability/aesthetic advantage, it's arguable that there's no
• Tom (5/10) Feb 28 2006 No no no, excuse me, nobody argues that because everybody knows that '{'...
• James Dunne (17/35) Feb 28 2006 Gosh I couldn't stand looking at all those wasted lines. C# default
• Sean Kelly (6/14) Feb 28 2006 It perhaps sidesteps the issue, but I use "for(;;)" in these cases,
• Ivan Senji (26/58) Feb 27 2006 LOL, 1 is a perfectly safe integer, but not a safe boolean.
• Tom (4/10) Feb 27 2006 Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I ...
• Ivan Senji (2/12) Feb 27 2006 LOL, So true :)
• Lucas Goss (11/24) Feb 27 2006 I don't understand this either. Just because I did things in C/C++ (I
• Oskar Linde (13/26) Feb 28 2006 Does pure booleans necessarily mean that other types could not be
• Kyle Furlong (3/39) Feb 28 2006 I would say that the second construct is much less reliable, maintainabl...
• Oskar Linde (21/33) Feb 28 2006 I have seen bugs introduced by changing
• Ivan Senji (21/66) Feb 28 2006 I would argue that the bug in the first place is coding something like
• Ivan Senji (2/42) Feb 28 2006 Ah, you can't explain that to a nonbeliever. :)
• Don Clugston (19/41) Feb 28 2006 I agree. I think implicit bool in conditionals is important,
• Walter Bright (10/13) Feb 28 2006 One should be very careful about stepping away from C's implicit promoti...
• Oskar Linde (22/31) Feb 28 2006 I agree. I also find while(5) to be perfectly acceptable. But the
• Tom (21/34) Feb 28 2006 So it's because you think that leaving C bools has more "marketing" and ...
• Derek Parnell (9/25) Feb 28 2006 How would disallowing arithmetic on bools make D like Pascal, or bring
• Ivan Senji (15/30) Feb 28 2006 I don't feel like writing any more about this: but here goes one more...
• Carlos Santander (7/20) Feb 28 2006 That depends on how you code and what you code. I recently wrote a 1600+...
• Roberto Mariottini (40/45) Mar 01 2006 This is untrue. Pascal is a strong-typed language for application progra...
• Tom (4/9) Mar 01 2006 Mmmh? Or I'm totally wasted or Walter didn't say that?
• Bruno Medeiros (15/25) Mar 02 2006 Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you
• Don Clugston (12/35) Mar 02 2006 I think one use case that is important is to be able to use bool to
• Bruno Medeiros (8/39) Mar 03 2006 Don't hamper D because of that. Better solution then is to keep that
• Tom (5/26) Mar 02 2006 You should read the latest posts about this stuff (the most with subject...
• Don Clugston (14/41) Mar 03 2006 Sorry, that's still not clear.
• Kyle Furlong (3/54) Mar 03 2006 I tend to want a boolean that is an operand of the boolean algebra and n...
• Bruno Medeiros (35/86) Mar 03 2006 Exactly, the "pure bools" must be defined by a set of language
• Tom (5/44) Mar 03 2006 And that is exactly what I meant when I said that you should read the la...
• Don Clugston (13/57) Mar 03 2006 And if you read that post, you will find that Derek said:
• xs0 (24/89) Mar 03 2006 Hmm, how about an expansion of (d):
• Ivan Senji (7/39) Mar 03 2006 Ok, I (as a bool purist) will not be satisfied with that & and | part.
• xs0 (18/49) Mar 03 2006 They are bitwise operations on integers, because that's what they're
• Ivan Senji (15/58) Mar 03 2006 Ok, now I understand what you're saying. But to have that behaviour we
• xs0 (27/44) Mar 06 2006 Sure, it has an easy "workaround", but like I said, I don't think the
• Ivan Senji (13/46) Mar 06 2006 Sure, only question: does it makes sense to do that? Judging by the
• Oskar Linde (12/45) Mar 03 2006 Yes, this is very similar to the definition I have suggested. I think
• xs0 (17/58) Mar 03 2006 Yup, but I think it's good that with
• Tom (4/61) Mar 03 2006 You are right. So lets just call (c) "Derek's Bool".
• Ivan Senji (10/34) Mar 03 2006 I'm not against casting but implicit conversions are bad.
• Oskar Linde (7/20) Mar 03 2006 Why? Ever heard of boolean algebra? Why should &,|,^,~ not be defined
• Ivan Senji (10/39) Mar 03 2006 I learned from xs0's reply that Java uses &,| for non-short-circuit
• Oskar Linde (17/55) Mar 03 2006 && and || controls the program flow. They are not algebraic operators.
• Ivan Senji (20/67) Mar 03 2006 If's and while's containing them control program flow (or I didn't get
• Oskar Linde (21/44) Mar 04 2006 They control program flow by themselves too:
• Ivan Senji (9/72) Mar 04 2006 Cool, I am never going to use if,then,else again ;)
• Miles (3/7) Mar 04 2006 Err... what you want is just: a != b
• Oskar Linde (8/16) Mar 05 2006 I apologize. I didn't notice that KNode put a single group
• Miles (14/19) Mar 05 2006 It is a bug, indeed. See https://bugs.kde.org/show_bug.cgi?id=68732 .
• Walter Bright (16/34) Feb 28 2006 The while expression must be convertible to a boolean, it needn't be a
• Lionello Lunesu (2/6) Feb 28 2006 That's actually the best point so far. I agree.
• Bruno Medeiros (16/36) Feb 28 2006 Thinking about that (the Pascal verbosity), I find that in most cases I
• Ivan Senji (10/23) Feb 27 2006 One more thing. I heared from a Ruby user that in Ruby 0 means true.
• Deewiant (4/5) Feb 27 2006 To clarify, since that makes it sound a bit too much like "...and 1 mean...
• Ivan Senji (5/13) Feb 27 2006 Thanks for the clarification. It is really interesting how Ruby takes a
• Deewiant (16/33) Feb 27 2006 Probably because of Ruby's TIMTOWTDI approach - There Is More Than One W...
• Charles Hixson (14/19) Feb 27 2006 Yes. IIRC in Ruby everything except Null and False is handled as if it ...
• Derek Parnell (20/52) Feb 26 2006 But D currently allows this to happen. It's boolean implementation is
• Derek Parnell (26/46) Feb 26 2006 That's okay, you don't have to be embarrassed amongst friends. There are
• Ivan Senji (13/30) Feb 26 2006 What? Did you here this correctly? You are saying remove logical
• Georg Wrede (9/32) Feb 26 2006 If Booleans are only 0 or 1, then & and | suffice. && and || become
• Ivan Senji (10/60) Feb 26 2006 That is one part I didn't understand. Why would booleans have to be 0 or...
• Georg Wrede (4/7) Feb 26 2006 Since anything stored on a computer is representable with numbers, then
• Ivan Senji (4/17) Feb 26 2006 Starting to like this proposal but I would prefer true to be 42 (being
• BCS (2/9) Feb 26 2006 Ouch! And false must then be 54. (6*9) :P
• Kyle Furlong (4/48) Feb 26 2006 Georg, reading your posts on this NG has given me great insight into the...
• Georg Wrede (6/16) Feb 26 2006 Thanks!
• Tom (7/23) Feb 26 2006 Me too, have to work and study tomorrow, shouldn't have "wasted" so much...
• Ivan Senji (2/28) Feb 26 2006 Me too. NG chating is a funny thing.
• Derek Parnell (18/37) Feb 26 2006 Why? And do you mean they have to be implemented using 'int' or are you ...
• James Dunne (6/70) Feb 26 2006 I actually laughed out loud at that. Good catch man. This is why I
• Wang Zhen (11/62) Feb 26 2006 32-bit int is frequently used to implement the concept of integers, but
• Kyle Furlong (4/74) Feb 26 2006 The point has to do with the type system. Yes, you can always hack any t...
• Derek Parnell (37/94) Feb 26 2006 I understood that a 32-bit int was used to implement a subset of integer...
• Ivan Senji (7/44) Feb 26 2006 Very simple concept indeed.
• Charles (2/50) Feb 26 2006
• Thomas Kuehne (12/15) Feb 26 2006 -----BEGIN PGP SIGNED MESSAGE-----
• Regan Heath (16/26) Feb 26 2006 So?
• Derek Parnell (11/40) Feb 26 2006 If it implemented that way, yes. However the problem with
• Regan Heath (6/51) Feb 26 2006 Sure, but the example was old C code, presumably copied into a D source ...
• Ivan Senji (7/71) Feb 26 2006 I usually want my code not only to likely work. That is just not enough.
• Regan Heath (7/78) Feb 26 2006 By "likely" I actually meant it "will definately" work provided it is
• Thomas Kuehne (29/60) Feb 26 2006 -----BEGIN PGP SIGNED MESSAGE-----
• Regan Heath (5/9) Feb 26 2006 I'm no assembler expert but isn't there a single instruction for compari...
• Walter Bright (5/23) Feb 27 2006 The next line goes around the type system completely, invalidates any
• Thomas Kuehne (26/37) Feb 28 2006 -----BEGIN PGP SIGNED MESSAGE-----
• Walter Bright (7/9) Feb 28 2006 That's true, but I disagree with the intent. When interfacing with C, or...
• Derek Parnell (6/9) Feb 26 2006 Should a coder be allowed by the compiler to perform arithemtic operatio...
• Georg Wrede (3/12) Feb 26 2006 No.
• Derek Parnell (13/27) Feb 26 2006 Then why the objection to having them as booleans rather than numbers?
• John Reimer (11/17) Feb 25 2006 :P
• Thomas Kuehne (12/15) Feb 25 2006 -----BEGIN PGP SIGNED MESSAGE-----
• Dave (8/25) Feb 26 2006 With an eye toward integrating rdmd with the compiler (as is mentioned i...
• Thomas Kuehne (117/127) Feb 26 2006 -----BEGIN PGP SIGNED MESSAGE-----
• Ivan Senji (4/6) Feb 26 2006 Cool things added, cool things removed but when is bool going to be adde...
• Russ Lewis (21/25) Mar 07 2006 FWIW, here's a(nother) practical example why bools-that-are-not-ints
"Walter Bright" <newshound digitalmars.com> writes:
```Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

http://www.digitalmars.com/d/changelog.html
```
Feb 25 2006
"Derek Parnell" <derek psych.ward> writes:
```On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright
<newshound digitalmars.com> wrote:

Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

Well you almost got bool right <G> Everything except that it does implicit
conversion to int. That is just a cheap cop out for lazy coding, IMNSHO.

//--------------------
import std.stdio;

void main()
{
bool a;
bool b;
bool c;
bool d;
int e;

a = true;
b = true;
c = true;
d = a + b + c;
e = a + b + c; // In a decent implentation, this should have failed to
compile
writefln("%s %s %s %s %s", a,b,c,d,e);
writefln("%d %d %d %d %d", a,b,c,d,e); // And this might have been a
runtime error?

}
//-------------------
--
Derek Parnell
Melbourne, Australia
```
Feb 25 2006
Tom <Tom_member pathlink.com> writes:
```In article <op.s5kaquba6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...
On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright

[snip]

d = a + b + c;

Sorry, how is the above different than the next?

e = a + b + c; // In a decent implentation, this should have failed to
compile

I mean, in a decent implementation, would it be right to allow '+' (numeric add
operator) between boolean vars?

Regards,

Tom;
```
Feb 25 2006
"Derek Parnell" <derek psych.ward> writes:
```On Sun, 26 Feb 2006 15:33:18 +1100, Tom <Tom_member pathlink.com> wrote:

In article <op.s5kaquba6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell
says...
On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright

[snip]

d = a + b + c;

Sorry, how is the above different than the next?

e = a + b + c; // In a decent implentation, this should have failed to
compile

I mean, in a decent implementation, would it be right to allow '+'
(numeric add
operator) between boolean vars?

No it wouldn't either. I rushed my response as I was going out visiting my
Dad - he turned 74 today.

--
Derek Parnell
Melbourne, Australia
```
Feb 25 2006
Tom <Tom_member pathlink.com> writes:
```In article <op.s5kj5uym6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...
On Sun, 26 Feb 2006 15:33:18 +1100, Tom <Tom_member pathlink.com> wrote:

In article <op.s5kaquba6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell
says...
On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright

[snip]

d = a + b + c;

Sorry, how is the above different than the next?

e = a + b + c; // In a decent implentation, this should have failed to
compile

I mean, in a decent implementation, would it be right to allow '+'
(numeric add
operator) between boolean vars?

No it wouldn't either. I rushed my response as I was going out visiting my
Dad - he turned 74 today.

That's ok, i see. :-) Wish your dad a happy birthday.

Regards,

Tom;
```
Feb 26 2006
Wang Zhen <nehzgnaw gmail.com> writes:
```Derek Parnell wrote:
On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright
<newshound digitalmars.com> wrote:

Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

Well you almost got bool right <G> Everything except that it does
implicit  conversion to int. That is just a cheap cop out for lazy
coding, IMNSHO.

Pardon my ignorance, but why does D need a primitive type for booleans
in the first place? What's wrong with "alias ubyte bool;" or "alias int
bool;"? Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

//--------------------
import std.stdio;

void main()
{
bool a;
bool b;
bool c;
bool d;
int e;

a = true;
b = true;
c = true;
d = a + b + c;
e = a + b + c; // In a decent implentation, this should have failed
to  compile
writefln("%s %s %s %s %s", a,b,c,d,e);
writefln("%d %d %d %d %d", a,b,c,d,e); // And this might have been a
runtime error?

}
//-------------------

```
Feb 25 2006
Kyle Furlong <kylefurlong gmail.com> writes:
```Wang Zhen wrote:
Derek Parnell wrote:
On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright
<newshound digitalmars.com> wrote:

Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

Well you almost got bool right <G> Everything except that it does
implicit  conversion to int. That is just a cheap cop out for lazy
coding, IMNSHO.

Pardon my ignorance, but why does D need a primitive type for booleans
in the first place? What's wrong with "alias ubyte bool;" or "alias int
bool;"? Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

//--------------------
import std.stdio;

void main()
{
bool a;
bool b;
bool c;
bool d;
int e;

a = true;
b = true;
c = true;
d = a + b + c;
e = a + b + c; // In a decent implentation, this should have failed
to  compile
writefln("%s %s %s %s %s", a,b,c,d,e);
writefln("%d %d %d %d %d", a,b,c,d,e); // And this might have been
a  runtime error?

}
//-------------------

Because there exists a boolean type that has different contstraints than a
normal integral type. In a good type system, these
are enforced by the compiler with a builtin type. Search for Derek's post about
it in the D NG.
```
Feb 25 2006
"Derek Parnell" <derek psych.ward> writes:
```On Sun, 26 Feb 2006 17:29:03 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:

Derek Parnell wrote:
On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright
<newshound digitalmars.com> wrote:

Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

Well you almost got bool right <G> Everything except that it does
implicit  conversion to int. That is just a cheap cop out for lazy
coding, IMNSHO.

Pardon my ignorance,

That's okay.

but why does D need a primitive type for booleans in the first place?
What's wrong with "alias ubyte bool;" or "alias int bool;"?

The short answer is that booleans are not numbers. They represent truth
and falsehood.

Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

*We* are not C programmers ;-) *We* have grown up from that baby-talk ;-)

Zero is frequently used to implement the concept of falsehood and likewise
non-zero for truth, however the semantics of integers is not the same as
the semantics of booleans. But because many C programers are just *so*
used to thinking this way they have become to believe that zero *is*
falsehood rather than just a number chosen to implement the concept.

It is quite possible for a language to implement falsehood/truth is ways
other than using integers but even if they do, the compiler can still
ensure that the sematics are adhered to rather than continue using integer
sematics.

The only thing I can see wrong with D's new boolean is that it still
pretends its a number. Why is this wrong? Because it can lead to coding
mistakes and abuse. Thus making maintenance more costly than it needed to
be.

Walter is still living in the C/C++ past with this concept, which is
strange seeing he has implemented so many progressive concepts in D.
Boolean as an integer is just retro.

--
Derek Parnell
Melbourne, Australia
```
Feb 25 2006
bobef <bobef lessequal.com> writes:
```Derek Parnell wrote:

Zero is frequently used to implement the concept of falsehood and
likewise non-zero for truth, however the semantics of integers is not
the same as the semantics of booleans. But because many C programers are
just *so* used to thinking this way they have become to believe that
zero *is* falsehood rather than just a number chosen to implement the
concept.

Just thoughts...

Well back in school we were learning boolean algebra. (for some
electrical crap... I don't remember... I don't care...). Even if we take
just the name 'boolean algebra' it means it used for calculations, which
means it is number not falsehood... After all it used for all these
logical operators which operate with numbers not falsehood... If we say
it is not calculations and it is logical operations, well it is not,
else it would be only true, false, if a to b is false and c to b is true
then a to c is ... this kind of stuff. But it is actually used for
numbers and calculations, because 01101010<<0202 is not logic anymore it
is mathematics which is also logic but other kind than true/false, logic
for the quantity of things not their rightness...
And one more thing. If it is falsehood indeed, then it is something
abstract. Technically speaking True and False have any meaning only in
the context of each other, i.e. in the context of some logic, system or
whatever, not in the context of numbers. So how are you going to convert
from number to falsehood? This would limit us to writing only bool
a=true || bool a=false, which seems annoying to me. bool a=1 is shorter
;]. Plus there will be no if(a), if(b), because a is always true or
always false by itself, it should relate to something else to be right
or wrong, so we will always have to write if(a==1), if(b==null) instead,
so I like it this way ;]

Am I talking nonsese? :)
```
Feb 26 2006
"Derek Parnell" <derek psych.ward> writes:
```On Sun, 26 Feb 2006 19:39:48 +1100, bobef <bobef lessequal.com> wrote:

Derek Parnell wrote:
Zero is frequently used to implement the concept of falsehood and
likewise non-zero for truth, however the semantics of integers is not
the same as the semantics of booleans. But because many C programers
are just *so* used to thinking this way they have become to believe
that zero *is* falsehood rather than just a number chosen to implement
the concept.

Just thoughts...

Well back in school we were learning boolean algebra. (for some
electrical crap... I don't remember... I don't care...). Even if we take
just the name 'boolean algebra' it means it used for calculations, which
means it is number not falsehood...

Not so. It is possible to create 'calculations' using purely logic
expressions. The result is not a number but one of 'false' or 'true' (or
unknown). Fuzzy logic calulations are more of a numerical field
(probablilty theory).

After all it used for all these logical operators which operate with
numbers not falsehood...

Well I'm sure it operates on relationships between numbers and not the
numbers themselves.

If we say it is not calculations and it is logical operations, well it
is not, else it would be only true, false, if a to b is false and c to b
is true then a to c is ... this kind of stuff. But it is actually used
for numbers and calculations, because 01101010<<0202 is not logic
anymore it is mathematics which is also logic but other kind than
true/false, logic for the quantity of things not their rightness...

Ok whatever ... but I was talking about what one gets when one compares
things with other things in relative terms or similar...

e.g.   a < b  ==> true or false

And one more thing. If it is falsehood indeed, then it is something
abstract. Technically speaking True and False have any meaning only in
the context of each other, i.e. in the context of some logic, system or
whatever, not in the context of numbers. So how are you going to convert
from number to falsehood?

By agreeing on a convention that is convenient.

This would limit us to writing only bool a=true || bool a=false, which
seems annoying to me. bool a=1 is shorter ;].

Yes it is shorter, but it is not descriptive of your intention. Did you
want 'a' to be set to 1 or to true? In other words, is the 'bool' a
mistake and really meant 'int'? Because the use of 1 in this way is
ambiguous it ought to be made cleaner / clearer to future maintainers.

Plus there will be no if(a), if(b), because a is always true or always
false by itself, it should relate to something else to be right or
wrong, so we will always have to write if(a==1), if(b==null) instead, so
I like it this way ;]

I take the syntax form  'if (<numeric-expression>)' to just be shorthand
for 'if (<numeric-expression> != 0)' and thus it would still be valid
syntax and get you the result you were expecting. No relaxation of boolean
sematrics is required.

Am I talking nonsese? :)

No.

--
Derek Parnell
Melbourne, Australia
```
Feb 26 2006
bobef <bobef lessequal.com> writes:
```Derek Parnell wrote:

In other words, is the 'bool' a
mistake and really meant 'int'? Because the use of 1 in this way is
ambiguous it ought to be made cleaner / clearer to future maintainers.

I think this is the case. In programming when one says bool, he actually
means int... So I believe making it real bool is something we don't
need, because it works just fine this way. What we have to do (maybe, I
don't need it personally) is to think of new name for a type which is
true relative to non zero and false relative to zero... Then it will
work with the current state of programming languages and will not
conflict with the name bool. Although in computers many words are uses
with different meaning... I don't know... I lost the original thought
already...
```
Feb 26 2006
Georg Wrede <georg nospam.org> writes:
```Derek Parnell wrote:
Walter is still living in the C/C++ past with this concept, which is
strange seeing he has implemented so many progressive concepts in D.
Boolean as an integer is just retro.

So am I.

Booleans have to be int. A boolean may have any "numeric" value, but if
implicitly cast to a numeric type, it should return 1 or 0.

D IS A PRACTICAL PROGRAMMING LANGUAGE.

Forcing booleans to be 1/0 all the way is just academic, purist,
impractical bigotry. About as smart as having the bit type.

(Besides, if booleans, as some say here, are _only_ abstract concepts,
then we might as well decide to have 0 mean true and 1 mean false. Heh,
there's only one truth but millions of lies! But we live in a world with
other people. And computers.)

Now, specifying 0 to mean false and everything else to mean not-false,
we go along with the hardware, the computer industry, half a century of
programming PRACTICE, and make life less difficult for anybody with a
professional programming background before moving to D.

Anybody who wants a tight-ass boolean, can define one for themselves.

////

Now off to the Olympic Final in ice hockey: Finland - Sweden!!!
```
Feb 26 2006
Kyle Furlong <kylefurlong gmail.com> writes:
```Georg Wrede wrote:
Derek Parnell wrote:
Walter is still living in the C/C++ past with this concept, which is
strange seeing he has implemented so many progressive concepts in D.
Boolean as an integer is just retro.

So am I.

Booleans have to be int. A boolean may have any "numeric" value, but if
implicitly cast to a numeric type, it should return 1 or 0.

D IS A PRACTICAL PROGRAMMING LANGUAGE.

Forcing booleans to be 1/0 all the way is just academic, purist,
impractical bigotry. About as smart as having the bit type.

(Besides, if booleans, as some say here, are _only_ abstract concepts,
then we might as well decide to have 0 mean true and 1 mean false. Heh,
there's only one truth but millions of lies! But we live in a world with
other people. And computers.)

Now, specifying 0 to mean false and everything else to mean not-false,
we go along with the hardware, the computer industry, half a century of
programming PRACTICE, and make life less difficult for anybody with a
professional programming background before moving to D.

Anybody who wants a tight-ass boolean, can define one for themselves.

////

Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a
boolean type, in all the old ways you describe?
Just as a curiosity, how have you been burned in the past by "purist" thinking
like this to make you so passionately against it?
```
Feb 26 2006
Tom <Tom_member pathlink.com> writes:
```In article <dtsgbj\$1h6u\$3 digitaldaemon.com>, Kyle Furlong says...
Georg Wrede wrote:
Derek Parnell wrote:
Walter is still living in the C/C++ past with this concept, which is
strange seeing he has implemented so many progressive concepts in D.
Boolean as an integer is just retro.

So am I.

Booleans have to be int. A boolean may have any "numeric" value, but if
implicitly cast to a numeric type, it should return 1 or 0.

D IS A PRACTICAL PROGRAMMING LANGUAGE.

Forcing booleans to be 1/0 all the way is just academic, purist,
impractical bigotry. About as smart as having the bit type.

(Besides, if booleans, as some say here, are _only_ abstract concepts,
then we might as well decide to have 0 mean true and 1 mean false. Heh,
there's only one truth but millions of lies! But we live in a world with
other people. And computers.)

Now, specifying 0 to mean false and everything else to mean not-false,
we go along with the hardware, the computer industry, half a century of
programming PRACTICE, and make life less difficult for anybody with a
professional programming background before moving to D.

Anybody who wants a tight-ass boolean, can define one for themselves.

////

Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a
boolean type, in all the old ways you describe?
Just as a curiosity, how have you been burned in the past by "purist" thinking
like this to make you so passionately against it?

I'd like to hear the answer :) .
Have to stay at the purists side on this one. I like bool to be bool cause I'm
that kind of guy that can't tolerate inconsistence (however I do tolerate it
cause don't have much of a choice right now) and I'm putting all my hope in D.
However both (the purist and the pragmatic) ways could coexist in the same
language I guess.

Tom;
```
Feb 26 2006
Wang Zhen <nehzgnaw gmail.com> writes:
```Tom wrote:
In article <dtsgbj\$1h6u\$3 digitaldaemon.com>, Kyle Furlong says...

Georg Wrede wrote:

Derek Parnell wrote:

Walter is still living in the C/C++ past with this concept, which is
strange seeing he has implemented so many progressive concepts in D.
Boolean as an integer is just retro.

So am I.

Booleans have to be int. A boolean may have any "numeric" value, but if
implicitly cast to a numeric type, it should return 1 or 0.

D IS A PRACTICAL PROGRAMMING LANGUAGE.

Forcing booleans to be 1/0 all the way is just academic, purist,
impractical bigotry. About as smart as having the bit type.

(Besides, if booleans, as some say here, are _only_ abstract concepts,
then we might as well decide to have 0 mean true and 1 mean false. Heh,
there's only one truth but millions of lies! But we live in a world with
other people. And computers.)

Now, specifying 0 to mean false and everything else to mean not-false,
we go along with the hardware, the computer industry, half a century of
programming PRACTICE, and make life less difficult for anybody with a
professional programming background before moving to D.

Anybody who wants a tight-ass boolean, can define one for themselves.

////

Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a
boolean type, in all the old ways you describe?
Just as a curiosity, how have you been burned in the past by "purist" thinking
like this to make you so passionately against it?

I'd like to hear the answer :) .
Have to stay at the purists side on this one. I like bool to be bool cause I'm
that kind of guy that can't tolerate inconsistence (however I do tolerate it
cause don't have much of a choice right now) and I'm putting all my hope in D.
However both (the purist and the pragmatic) ways could coexist in the same
language I guess.

Tom;

I'm curious to know how you can tolerate the much impure int and real
types while highly demanding a pure boolean. An integer bool is at least
a superset of true booleans. Does that really bother people more?
```
Feb 26 2006
"Derek Parnell" <derek psych.ward> writes:
```On Mon, 27 Feb 2006 02:59:42 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:

I'm curious to know how you can tolerate the much impure int and real
types while highly demanding a pure boolean. An integer bool is at least
a superset of true booleans. Does that really bother people more?

'int' is not impure. It is a defined subset of integers.
'real' is not impure. It is a defined subset of reals.

'int' is not a superset of boolean. They are in different domains. You
seem to be confusing implementation with theory.

--
Derek Parnell
Melbourne, Australia
```
Feb 26 2006
Kyle Furlong <kylefurlong gmail.com> writes:
```Derek Parnell wrote:
On Mon, 27 Feb 2006 02:59:42 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:

I'm curious to know how you can tolerate the much impure int and real
types while highly demanding a pure boolean. An integer bool is at
least a superset of true booleans. Does that really bother people more?

'int' is not impure. It is a defined subset of integers.
'real' is not impure. It is a defined subset of reals.

'int' is not a superset of boolean. They are in different domains. You
seem to be confusing implementation with theory.

--Derek Parnell
Melbourne, Australia

This is what happens when the theorists collide with the hobbyists. ;(
```
Feb 26 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Wang Zhen wrote:
I'm curious to know how you can tolerate the much impure int and real
types while highly demanding a pure boolean. An integer bool is at least
a superset of true booleans. Does that really bother people more?

A superset? Hmmm, integer bool has nothing to do with true booleans.
And int and real would be impure why? Their behaviour is well defined
and consistent.
```
Feb 26 2006
Tom <Tom_member pathlink.com> writes:
```In article <dtsj9u\$1l2s\$1 digitaldaemon.com>, Wang Zhen says...
Tom wrote:
In article <dtsgbj\$1h6u\$3 digitaldaemon.com>, Kyle Furlong says...

Georg Wrede wrote:

Derek Parnell wrote:

Walter is still living in the C/C++ past with this concept, which is
strange seeing he has implemented so many progressive concepts in D.
Boolean as an integer is just retro.

So am I.

Booleans have to be int. A boolean may have any "numeric" value, but if
implicitly cast to a numeric type, it should return 1 or 0.

D IS A PRACTICAL PROGRAMMING LANGUAGE.

Forcing booleans to be 1/0 all the way is just academic, purist,
impractical bigotry. About as smart as having the bit type.

(Besides, if booleans, as some say here, are _only_ abstract concepts,
then we might as well decide to have 0 mean true and 1 mean false. Heh,
there's only one truth but millions of lies! But we live in a world with
other people. And computers.)

Now, specifying 0 to mean false and everything else to mean not-false,
we go along with the hardware, the computer industry, half a century of
programming PRACTICE, and make life less difficult for anybody with a
professional programming background before moving to D.

Anybody who wants a tight-ass boolean, can define one for themselves.

////

Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a
boolean type, in all the old ways you describe?
Just as a curiosity, how have you been burned in the past by "purist" thinking
like this to make you so passionately against it?

I'd like to hear the answer :) .
Have to stay at the purists side on this one. I like bool to be bool cause I'm
that kind of guy that can't tolerate inconsistence (however I do tolerate it
cause don't have much of a choice right now) and I'm putting all my hope in D.
However both (the purist and the pragmatic) ways could coexist in the same
language I guess.

Tom;

I'm curious to know how you can tolerate the much impure int and real
types while highly demanding a pure boolean. An integer bool is at least
a superset of true booleans. Does that really bother people more?

I think people learns to tolerate things. It's just a matter of time. And now
that you mention it, it doesn't bother me *that* much. Now it is more like a
preference to me.

Tom;
```
Feb 26 2006
Tom <Tom_member pathlink.com> writes:
```In article <dttblu\$2hr6\$1 digitaldaemon.com>, Tom says...
In article <dtsj9u\$1l2s\$1 digitaldaemon.com>, Wang Zhen says...
Tom wrote:
In article <dtsgbj\$1h6u\$3 digitaldaemon.com>, Kyle Furlong says...

Georg Wrede wrote:

Derek Parnell wrote:

Walter is still living in the C/C++ past with this concept, which is
strange seeing he has implemented so many progressive concepts in D.
Boolean as an integer is just retro.

So am I.

Booleans have to be int. A boolean may have any "numeric" value, but if
implicitly cast to a numeric type, it should return 1 or 0.

D IS A PRACTICAL PROGRAMMING LANGUAGE.

Forcing booleans to be 1/0 all the way is just academic, purist,
impractical bigotry. About as smart as having the bit type.

(Besides, if booleans, as some say here, are _only_ abstract concepts,
then we might as well decide to have 0 mean true and 1 mean false. Heh,
there's only one truth but millions of lies! But we live in a world with
other people. And computers.)

Now, specifying 0 to mean false and everything else to mean not-false,
we go along with the hardware, the computer industry, half a century of
programming PRACTICE, and make life less difficult for anybody with a
professional programming background before moving to D.

Anybody who wants a tight-ass boolean, can define one for themselves.

////

Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using integers as a
boolean type, in all the old ways you describe?
Just as a curiosity, how have you been burned in the past by "purist" thinking
like this to make you so passionately against it?

I'd like to hear the answer :) .
Have to stay at the purists side on this one. I like bool to be bool cause I'm
that kind of guy that can't tolerate inconsistence (however I do tolerate it
cause don't have much of a choice right now) and I'm putting all my hope in D.
However both (the purist and the pragmatic) ways could coexist in the same
language I guess.

Tom;

I'm curious to know how you can tolerate the much impure int and real
types while highly demanding a pure boolean. An integer bool is at least
a superset of true booleans. Does that really bother people more?

I think people learns to tolerate things. It's just a matter of time. And now
that you mention it, it doesn't bother me *that* much. Now it is more like a
preference to me.

Sorry didn't understand before (part because of english not being my "home
language" and part because of being distracted). Derek answered well to that.
Now here is my thinking: if you don't like abstraction high level languages
offer, please go back to C or even to assembly so you never forget you're
dealing with transistors :P (just a joke)

Tom;
```
Feb 26 2006
Georg Wrede <georg nospam.org> writes:
```Tom wrote:
Kyle Furlong says...
Georg Wrede wrote:
Derek Parnell wrote:

Walter is still living in the C/C++ past with this concept,
which is strange seeing he has implemented so many progressive
concepts in D. Boolean as an integer is just retro.

So am I.

Booleans have to be int. A boolean may have any "numeric" value,
but if implicitly cast to a numeric type, it should return 1 or
0.

D IS A PRACTICAL PROGRAMMING LANGUAGE.

Forcing booleans to be 1/0 all the way is just academic, purist,
impractical bigotry. About as smart as having the bit type.

(Besides, if booleans, as some say here, are _only_ abstract
concepts, then we might as well decide to have 0 mean true and 1
mean false. Heh, there's only one truth but millions of lies! But
we live in a world with other people. And computers.)

Now, specifying 0 to mean false and everything else to mean
not-false, we go along with the hardware, the computer industry,
half a century of programming PRACTICE, and make life less
difficult for anybody with a professional programming background
before moving to D.

Anybody who wants a tight-ass boolean, can define one for
themselves.

////

Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using
integers as a boolean type, in all the old ways you describe? Just
as a curiosity, how have you been burned in the past by "purist"
thinking like this to make you so passionately against it?

I'd like to hear the answer :) . Have to stay at the purists side on
this one. I like bool to be bool cause I'm that kind of guy that
can't tolerate inconsistence (however I do tolerate it cause don't
have much of a choice right now) and I'm putting all my hope in D.
However both (the purist and the pragmatic) ways could coexist in the
same language I guess.

Well, then we could skip the logical operators, right? No more && or ||.
Since all booleans would be strictly 0 or 1, they'd become obsolete.

And if booleans have to only be 0 or 1, then a whole lot of unnecessary
conversions would be happening all over the place. Forget D speed.

Also, D is supposed to be a _systems_language_ for chrissake! Any kernel
writing would then have to forgo booleans totally.

I'm all for features in D that enhance productivity, but deliberately
dumbing down the language is getting a bit too far.

---

We've all had our fights with C, C++, and other related languages. But
honestly, how many of us can confess to having problems with logical values?

And if someone here has such problems, I suggest switching to VB.

---

"Don't fix it if it ain't broke."
```
Feb 26 2006
Kyle Furlong <kylefurlong gmail.com> writes:
```Georg Wrede wrote:
Tom wrote:
Kyle Furlong says...
Georg Wrede wrote:
Derek Parnell wrote:

Walter is still living in the C/C++ past with this concept,
which is strange seeing he has implemented so many progressive
concepts in D. Boolean as an integer is just retro.

So am I.

Booleans have to be int. A boolean may have any "numeric" value,
but if implicitly cast to a numeric type, it should return 1 or
0.

D IS A PRACTICAL PROGRAMMING LANGUAGE.

Forcing booleans to be 1/0 all the way is just academic, purist,
impractical bigotry. About as smart as having the bit type.

(Besides, if booleans, as some say here, are _only_ abstract
concepts, then we might as well decide to have 0 mean true and 1
mean false. Heh, there's only one truth but millions of lies! But
we live in a world with other people. And computers.)

Now, specifying 0 to mean false and everything else to mean
not-false, we go along with the hardware, the computer industry,
half a century of programming PRACTICE, and make life less
difficult for anybody with a professional programming background
before moving to D.

Anybody who wants a tight-ass boolean, can define one for
themselves.

////

Now off to the Olympic Final in ice hockey: Finland - Sweden!!!

How would having a builtin, "purist" boolean type preclude using
integers as a boolean type, in all the old ways you describe? Just
as a curiosity, how have you been burned in the past by "purist"
thinking like this to make you so passionately against it?

I'd like to hear the answer :) . Have to stay at the purists side on
this one. I like bool to be bool cause I'm that kind of guy that
can't tolerate inconsistence (however I do tolerate it cause don't
have much of a choice right now) and I'm putting all my hope in D.
However both (the purist and the pragmatic) ways could coexist in the
same language I guess.

Well, then we could skip the logical operators, right? No more && or ||.
Since all booleans would be strictly 0 or 1, they'd become obsolete.

And if booleans have to only be 0 or 1, then a whole lot of unnecessary
conversions would be happening all over the place. Forget D speed.

Why would this happen?

Also, D is supposed to be a _systems_language_ for chrissake! Any kernel
writing would then have to forgo booleans totally.

I'm wracking my brain for any reason why this statement is even remotely true.

I'm all for features in D that enhance productivity, but deliberately
dumbing down the language is getting a bit too far.

How is it dumbing down the language to instruct it in the correct contraints of
the boolean type?

---

We've all had our fights with C, C++, and other related languages. But
honestly, how many of us can confess to having problems with logical
values?

And if someone here has such problems, I suggest switching to VB.

---

"Don't fix it if it ain't broke."

Many would contend that it is, as you say, "broke."
```
Feb 26 2006
"Derek Parnell" <derek psych.ward> writes:
```On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org> wrote:

Well, then we could skip the logical operators, right? No more && or ||.
Since all booleans would be strictly 0 or 1, they'd become obsolete.

Firstly, I'm not saying that booleans are 0 or 1 - they are not even
numbers.

Secondly, '&&' and '||' are logic operations and don't apply to numbers,
they apply to booleans.

if ((a < b) && (c >= b)) ...

has meaning regardless of how booleans are implemented.

And if booleans have to only be 0 or 1, then a whole lot of unnecessary
conversions would be happening all over the place. Forget D speed.

I repeat ... why are you saying the 0/1 is the only implementation being
suggested? I'm not holding that position. Booleans can be implemented
efficiently, and the compiler can implement boolean semantics, these are
not mutually exclusive.

Also, D is supposed to be a _systems_language_ for chrissake! Any kernel
writing would then have to forgo booleans totally.

Why? Your statement does not make any sense to me.

I'm all for features in D that enhance productivity, but deliberately
dumbing down the language is getting a bit too far.

You mean that by making D smarter about the use of booleans would actually
make it dumber?

We've all had our fights with C, C++, and other related languages. But
honestly, how many of us can confess to having problems with logical
values?

Me.

And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

"Don't fix it if it ain't broke."

D is broken with respect to booleans. A little less broken than before,
but still broken.

--
Derek Parnell
Melbourne, Australia
```
Feb 26 2006
Georg Wrede <georg nospam.org> writes:
```Derek Parnell wrote:
On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org> wrote:

We've all had our fights with C, C++, and other related languages.
But  honestly, how many of us can confess to having problems with
logical  values?

Me.

And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future.

---

I think we've gotten it backwards here, so let's turn the table:

Can you give some example code and use cases where we absolutely need
your kind of booleans?
```
Feb 26 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Georg Wrede wrote:
Derek Parnell wrote:

On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org> wrote:

We've all had our fights with C, C++, and other related languages.
But  honestly, how many of us can confess to having problems with
logical  values?

Me.

And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future.

---

I think we've gotten it backwards here, so let's turn the table:

Can you give some example code and use cases where we absolutely need
your kind of booleans?

Ok, I'll give an example of that right after you give an example of why
and where this is needed/good/(not extremly bad):

bool a, b, c;
a = true;
b = true;
c = true;

a = b+c; // true + true is what?

if(5) //if 5 what? what does that mean (except nothing)?
{
writefln("5");
}
```
Feb 26 2006
Georg Wrede <georg nospam.org> writes:
```Ivan Senji wrote:
Georg Wrede wrote:

Derek Parnell wrote:

On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org>
wrote:

We've all had our fights with C, C++, and other related languages.
But  honestly, how many of us can confess to having problems with
logical  values?

Me.

And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future.

---

I think we've gotten it backwards here, so let's turn the table:

Can you give some example code and use cases where we absolutely need
your kind of booleans?

Ok, I'll give an example of that right after you give an example of why
and where this is needed/good/(not extremly bad):

bool a, b, c;
a = true;
b = true;
c = true;

a = b+c; // true + true is what?

That's why we do want to have booleans. The whole point of having
booleans is to not do that by mistake.

if(5) //if 5 what? what does that mean (except nothing)?

Ever seen this:

while(1)

written in source code?

Or this:

c = getCharacter(inf);
if (c) { /* whatever */ }

Oh, by the way, just checked how many times 'while(1)' appears in
src/phobos/std:

grep "while *( *1 *)" *.d |wc

answer: 16 times.

---

Now, let's see your promised example.
```
Feb 26 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Georg Wrede wrote:
Ivan Senji wrote:

Georg Wrede wrote:

Derek Parnell wrote:

On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org>
wrote:

We've all had our fights with C, C++, and other related languages.
But  honestly, how many of us can confess to having problems with
logical  values?

Me.

And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future.

---

I think we've gotten it backwards here, so let's turn the table:

Can you give some example code and use cases where we absolutely need
your kind of booleans?

Could it be that I missunderstood you? By your kind of booleans did you
mean the true non-integer booleans? If so, that is what the example dow
there is for: showing why we need real bools.

And if I did missunderstand something I apologize (it's late).

Ok, I'll give an example of that right after you give an example of
why and where this is needed/good/(not extremly bad):

bool a, b, c;
a = true;
b = true;
c = true;

a = b+c; // true + true is what?

That's why we do want to have booleans. The whole point of having
booleans is to not do that by mistake.

Are you now saying you want real booleans that are not ints?

if(5) //if 5 what? what does that mean (except nothing)?

Ever seen this:

while(1)

I sure did, and it scares the hell out of me :)

written in source code?

Or this:

c = getCharacter(inf);
if (c) { /* whatever */ }

...even worse :)

Oh, by the way, just checked how many times 'while(1)' appears in
src/phobos/std:

grep "while *( *1 *)" *.d |wc

answer: 16 times.

Scary.

---

Now, let's see your promised example.

My example was supposed to be an example for:
a) real bools being needed
b) int bool being bad
```
Feb 26 2006
Georg Wrede <georg nospam.org> writes:
```Ivan Senji wrote:
Georg Wrede wrote:

Ivan Senji wrote:

Georg Wrede wrote:

Derek Parnell wrote:

On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org>
wrote:

We've all had our fights with C, C++, and other related languages.
But  honestly, how many of us can confess to having problems with
logical  values?

Me.

And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future.

---

I think we've gotten it backwards here, so let's turn the table:

Can you give some example code and use cases where we absolutely
need your kind of booleans?

Could it be that I missunderstood you? By your kind of booleans did you
mean the true non-integer booleans? If so, that is what the example dow
there is for: showing why we need real bools.

And if I did missunderstand something I apologize (it's late).

No problem. The way this whole thread is going, half the time everybody
is clueless. :-)

Ok, I'll give an example of that right after you give an example of
why and where this is needed/good/(not extremly bad):

bool a, b, c;
a = true;
b = true;
c = true;

a = b+c; // true + true is what?

That's why we do want to have booleans. The whole point of having
booleans is to not do that by mistake.

Are you now saying you want real booleans that are not ints?

On the inside they should be ints. Mostly for efficiency reasons, but
also for established coding conventions.

But on the outside, they should not be compatible with ints.

In other words, doing

bool foo = 55 && 5000;

should be legal, and it should store the 'true value' (that'd be a 1)
into foo.

But doing:

bool a = 1;  // legal, but poor coding
bool b = 0;  // likewise
whateverType bar = a + b;  // should produce a compiler error
// since addition of bools is illegal

if(5) //if 5 what? what does that mean (except nothing)?

Ever seen this:

while(1)

I sure did, and it scares the hell out of me :)

written in source code?

Or this:

c = getCharacter(inf);
if (c) { /* whatever */ }

...even worse :)
Oh, by the way, just checked how many times 'while(1)' appears in
src/phobos/std:

grep "while *( *1 *)" *.d |wc

answer: 16 times.

Scary.

Now, let's see your promised example.

My example was supposed to be an example for:
a) real bools being needed
b) int bool being bad

I'm still waiting.
```
Feb 26 2006
Tom <Tom_member pathlink.com> writes:
```In article <44024375.4060101 nospam.org>, Georg Wrede says...
Ivan Senji wrote:
Georg Wrede wrote:

Ivan Senji wrote:

Georg Wrede wrote:

Derek Parnell wrote:

On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org>
wrote:

We've all had our fights with C, C++, and other related languages.
But  honestly, how many of us can confess to having problems with
logical  values?

Me.

And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future.

---

I think we've gotten it backwards here, so let's turn the table:

Can you give some example code and use cases where we absolutely
need your kind of booleans?

Could it be that I missunderstood you? By your kind of booleans did you
mean the true non-integer booleans? If so, that is what the example dow
there is for: showing why we need real bools.

And if I did missunderstand something I apologize (it's late).

No problem. The way this whole thread is going, half the time everybody
is clueless. :-)

Ok, I'll give an example of that right after you give an example of
why and where this is needed/good/(not extremly bad):

bool a, b, c;
a = true;
b = true;
c = true;

a = b+c; // true + true is what?

That's why we do want to have booleans. The whole point of having
booleans is to not do that by mistake.

Are you now saying you want real booleans that are not ints?

On the inside they should be ints. Mostly for efficiency reasons, but
also for established coding conventions.

But on the outside, they should not be compatible with ints.

In other words, doing

bool foo = 55 && 5000;

Oh my God!

should be legal, and it should store the 'true value' (that'd be a 1)
into foo.

But doing:

bool a = 1;  // legal, but poor coding
bool b = 0;  // likewise
whateverType bar = a + b;  // should produce a compiler error
// since addition of bools is illegal

if(5) //if 5 what? what does that mean (except nothing)?

Ever seen this:

while(1)

I sure did, and it scares the hell out of me :)

written in source code?

Or this:

c = getCharacter(inf);
if (c) { /* whatever */ }

...even worse :)
Oh, by the way, just checked how many times 'while(1)' appears in
src/phobos/std:

grep "while *( *1 *)" *.d |wc

answer: 16 times.

Scary.

Now, let's see your promised example.

My example was supposed to be an example for:
a) real bools being needed
b) int bool being bad

I'm still waiting.

Really I can't see yet why you don't like the pure bool. We should see an
example of why pure bools would bother you so much.

Tom;
```
Feb 26 2006
Georg Wrede <georg nospam.org> writes:
```Tom wrote:
Georg Wrede says...
Ivan Senji wrote:
Georg Wrede wrote:
Ivan Senji wrote:
Georg Wrede wrote:
Derek Parnell wrote:
Georg Wrede wrote:

I think we've gotten it backwards here, so let's turn the table:

Can you give some example code and use cases where we absolutely
need your kind of booleans?

Could it be that I missunderstood you? By your kind of booleans did you
mean the true non-integer booleans? If so, that is what the example dow
there is for: showing why we need real bools.

And if I did missunderstand something I apologize (it's late).

No problem. The way this whole thread is going, half the time everybody
is clueless. :-)

bool foo = 55 && 5000;

Oh my God!

Really I can't see yet why you don't like the pure bool. We should see an
example of why pure bools would bother you so much.

In this post alone, there's a half dozen references to "my kind of bool"
or "your kind of bool", by various people.

Probably somebody should start making a table of their properties! :-)

And if they don't, we could always examine this thread later, and I bet
we could find one or two pairs of folks vehemently arguing, and it'd
turn out "their bools were the same", only they didn't notice.
```
Feb 26 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Georg Wrede wrote:
Tom wrote:

Georg Wrede says...

Ivan Senji wrote:

Georg Wrede wrote:

Ivan Senji wrote:

Georg Wrede wrote:

Derek Parnell wrote:

Georg Wrede wrote:

This above looks cool.

I think we've gotten it backwards here, so let's turn the table:

Can you give some example code and use cases where we absolutely
need your kind of booleans?

Could it be that I missunderstood you? By your kind of booleans did
you mean the true non-integer booleans? If so, that is what the
example dow there is for: showing why we need real bools.

And if I did missunderstand something I apologize (it's late).

No problem. The way this whole thread is going, half the time
everybody is clueless. :-)

bool foo = 55 && 5000;

Oh my God!

Really I can't see yet why you don't like the pure bool. We should see an
example of why pure bools would bother you so much.

In this post alone, there's a half dozen references to "my kind of bool"
or "your kind of bool", by various people.

Funny thread.

Probably somebody should start making a table of their properties! :-)

And if they don't, we could always examine this thread later, and I bet
we could find one or two pairs of folks vehemently arguing, and it'd
turn out "their bools were the same", only they didn't notice.

After all, what ever bizare variant of a bool gets implemented, it is
still out D's bool :)
```
Feb 26 2006
Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
```Georg Wrede skrev:
Tom wrote:
Georg Wrede says...
Ivan Senji wrote:
Georg Wrede wrote:
Ivan Senji wrote:
Georg Wrede wrote:
Derek Parnell wrote:
Georg Wrede wrote:

[snip]

In this post alone, there's a half dozen references to "my kind of bool"
or "your kind of bool", by various people.

Probably somebody should start making a table of their properties! :-)

Lets try. First the two extremes:

Numerical bool
-------------
True is 1, false is 0. Math is computed in a modulo-2 algebra (the
result of all operations is computed mod (%) 2).
This bool is an integer type, and should also be implicitly castable to
int. Analogous to the unsigned integer types:

bool:   mod 2 algebra
ubyte:  mod 256 algebra
ushort: mod 65536 algebra
uint:   mod 4294967296 algebra
ulong:  mod 18446744073709551616 algebra

Boolean operators (&,|,^,~,...) works as expected and are implementable
efficiently. Arithmetic operators have the following properties:

+ behaves like xor (1+1 = 0)
* behaves like and

This type can be implemented efficiently as an (1, 2, 4, ...)-byte
integer by either a) always mask the result of any operation cast to a
bool by by &1 or b) consider all bits but the least significant to be
undefined (meaning mask &1 when cast to a longer type)

Downside: Even integers (2,4,...) would be cast into a boolean 0 (false).

This is the pure numeric bool type. CPU-friendly.

Logical bool
------------
True and false are the only allowed values of this boolean variable. The
internal representation is irrelevant.

Boolean operators behaves as expected. Arithmetic operators should
either be:

a) forbidden, or
b) defined as in boolean algebra (* == and, + == or, ~ == not).

This bool should not be implicitly convertible to anything and should
not be allowed to take place in arithmetics with other types.

Is this less CPU-friendly than a numerical bool? See comments below.

C++ bool, C99 _Bool
-------------------
C++ and C99 defines its boolean somewhere in between the Numerical and
the Logical boolean (i.e. gets none of them right). The bool type is
defined to be a numeric type implicitly castable to int (and therefore
promotes to int/uint). Casting anything (x) to a bool yields 1 unless x
== 0. This makes this bool-type quite different from a pure numeric
type:  (Consider x a boolean variable.)

There are no overflows:
++x, x++, x += 1 all sets x to 1.
But there are underflows:
--x, x--, x -= 1 flips the value of x.

Even though much caution is taken making sure a bool only ever has the
value 1 or 0, the integer promotion breaks everything:

bool a = true;
bool b = a+a;
assert(b == true); // OK
assert(a+a == true); // FAILS
assert(a+true == true); // FAILS
assert(true+true == true); // FAILS

Hence the rule: Never compare anything to true. (Or never use arithmetic
operations on a bool.)

Java boolean
------------
The Java boolean follows the definition of Logical bool above, and
disables arithmetic operators. Bools are never promoted to ints. Bools
can not even be cast to ints.

There are no caveats using the Java boolean type, but you occasionally
need to write a bit more code to make the compiler happy.

D bool
------
I'm not fully aware how bools now are defined in D. The basic idea seems
to be the same as C99/C++, but with one small difference:
- Can not implicitly convert integer literals other than 0 and 1 to bool.

This difference feels slightly inconsistent because you can implicitly
convert a non literal integer to a bool.

(There is also another difference that is likely a bug (*) )

Can anyone please fill in what other differences there are?

Comments
--------
Integer promotion makes "== true" a trap just waiting to be sprung for a
numerical bool. The advantages of being able to do arithmetics on a bool
are cases such as:

bool addPadding = something();
int pos = 10 + addPadding * 5;

Compared to:
int pos = 10 + addPadding ? 5 : 0;

Could help a compiler avoid a branching instruction... But you get the
branching when forcing the bool to {0,1} instead.

Are there any other advantages?

Could a logical bool not be defined as being true when !0 and false
otherwise, without the need to clamp it to {0,1}? Would this not be more
efficient than the current bool? This would mean that the argument
against opEquals returning a bool would vanish for instance. The only
thing that would be less efficient would be comparing two boolean
variables with each other (a rare occurrence) and that would not be less
efficient than today unless there are many more comparisons than
assignments.

With dead horses in mind, my suggestion would be to make the D bool a
_logical_ bool that is implicitly convertible _from_ any type that can
be used as a condition expression (if(...)) but not _to_ any other type.
Internal representation is irrelevant (could even be an ABI-thing).

/Oskar

---

*) The other difference in D bool that is likely a bug:
- Like C99/C++, D makes sure that anything (x) cast to a bool yields 1
unless x == 0, but differs when arithmetics are done on the bool type
itself:

bool a = 0;
--a;
assert(a == false || a == true); // FAILS(!) (a is set to 255)

bool t = true;
bool b = t+t;
assert(b == true); //OK
bool c = 0;
c++;
c++;
assert(c == true || c == false); // FAILS

But:

bool d = 0;
d += 2;
assert(d == true || d == false); // OK

The last case works due to promotion bool -> int -> bool but the failing
cases do not take that route.

(being consistent, the definitions of post/predec of a bool should be to
flip its value and post/preinc should set it to true)
```
Feb 27 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Georg Wrede wrote:
Ivan Senji wrote:
And if I did missunderstand something I apologize (it's late).

No problem. The way this whole thread is going, half the time everybody
is clueless. :-)

:)

Are you now saying you want real booleans that are not ints?

On the inside they should be ints. Mostly for efficiency reasons, but
also for established coding conventions.

I agree completly that on the inside they should be ints for some
reasons. But not as a must. On a different arhitecture something else
might be more efficient.

But on the outside, they should not be compatible with ints.

In other words, doing

bool foo = 55 && 5000;

should be legal,

You trying to scare me away from this thread? ;)

I believe programming language constructs should(mostly) be translatable
to a human language.
but:

if(55){Georg.giveApple();}

means:

if 55 give Georg an apple.

Does Georg expect to get an apple? I really don't know. This doesn't
have any meaning.

and it should store the 'true value' (that'd be a 1)
into foo.

If by "store the 'true value' into foo" you mean "compile time error:
cannot implicitly conver from int to bool" than I agree! :)

But doing:

bool a = 1;  // legal, but poor coding
bool b = 0;  // likewise
whateverType bar = a + b;  // should produce a compiler error
// since addition of bools is illegal

Hm! Addition of bools is illegal but assigning random integers into them
is OK.

My example was supposed to be an example for:
a) real bools being needed
b) int bool being bad

I'm still waiting.

No need to wait, the examples are there. :)
```
Feb 26 2006
Tom <Tom_member pathlink.com> writes:
```[snip]

This really looks like a chat by now. We should get into an IRC (despite I don't
personally like chatting over IRC kind of chats). :P

Tom;
```
Feb 26 2006
"Walter Bright" <newshound digitalmars.com> writes:
```"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:dttebh\$2kqq\$1 digitaldaemon.com...
Ever seen this:

while(1)

I sure did, and it scares the hell out of me :)

Why? This is a practice I got into with C/C++, and I did it because 1 cannot
be redefined by the preprocessor into something goofy. I.e., I *knew* what
it was without having to go spelunking through header files.
```
Feb 26 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Walter Bright wrote:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:dttebh\$2kqq\$1 digitaldaemon.com...

Ever seen this:

while(1)

I sure did, and it scares the hell out of me :)

Why? This is a practice I got into with C/C++, and I did it because 1 cannot
be redefined by the preprocessor into something goofy. I.e., I *knew* what
it was without having to go spelunking through header files.

The reason should be obvious. While(condition). Condition should be
boolean (true or false). 1 is neither. It is an integer. Using 1 (or any
other int) in a conditions place just isn't type safe.

What if you (as a compiler writer) decide (how ever unlikely) that true
should for some good reasons be implemented as being 0, or bool should
be implemented as float, or something else).

PS
No need to answer because I know this is one topic where we can't
convince you. :)
```
Feb 26 2006
Roberto Mariottini <Roberto_member pathlink.com> writes:
```In article <dtuatr\$l0k\$1 digitaldaemon.com>, Ivan Senji says...
Walter Bright wrote:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:dttebh\$2kqq\$1 digitaldaemon.com...

Ever seen this:

while(1)

I sure did, and it scares the hell out of me :)

Why? This is a practice I got into with C/C++, and I did it because 1 cannot
be redefined by the preprocessor into something goofy. I.e., I *knew* what
it was without having to go spelunking through header files.

The reason should be obvious. While(condition). Condition should be
boolean (true or false). 1 is neither. It is an integer. Using 1 (or any
other int) in a conditions place just isn't type safe.

One of my students once had code written like this:

bool b1 = ... complex expression ... ;
..
bool b2 = ... complex expression ... ;
..
bool b3 = ... complex expression ... ;
..
if (b1 || (b2 && 3))
{
.. remove the file ...
}

(note the 'b' missing from 'b3').
Its program obviously removed the file at every run, no matter how it set the
three variables, even when the debugger said they were false all the three.
When I explained the student that 3 is always true, he asked to me: "Why? What
'3' has in common with 'true'?". I didn't know what to say.
Then the students complained at me that the compiler was buggy, since it didn't
signal that construct as an error. It took me one hour to explain this C/C++
design flaw/decision, but I think I didn't convince them all.

Ciao
```
Feb 27 2006
"Walter Bright" <newshound digitalmars.com> writes:
```"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:dtuatr\$l0k\$1 digitaldaemon.com...
Walter Bright wrote:
Why? This is a practice I got into with C/C++, and I did it because 1
cannot be redefined by the preprocessor into something goofy. I.e., I
*knew* what it was without having to go spelunking through header files.

The reason should be obvious. While(condition). Condition should be
boolean (true or false). 1 is neither. It is an integer. Using 1 (or any
other int) in a conditions place just isn't type safe.

1 isn't type safe??

What if you (as a compiler writer) decide (how ever unlikely) that true
should for some good reasons be implemented as being 0, or bool should be
implemented as float, or something else).

That would break just about every C and C++ program in existence. Not going
to happen. The reason I used 1 was because *it could never break* and
because it has the property of being "inspectible." Inspectible means I can
look at it and know what it does without having to refer to other things.

PS No need to answer because I know this is one topic where we can't
convince you. :)

LOL, I agree with you there.
```
Feb 27 2006
Derek Parnell <derek psych.ward> writes:
```On Mon, 27 Feb 2006 13:49:14 -0800, Walter Bright wrote:

"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:dtuatr\$l0k\$1 digitaldaemon.com...
Walter Bright wrote:
Why? This is a practice I got into with C/C++, and I did it because 1
cannot be redefined by the preprocessor into something goofy. I.e., I
*knew* what it was without having to go spelunking through header files.

The reason should be obvious. While(condition). Condition should be
boolean (true or false). 1 is neither. It is an integer. Using 1 (or any
other int) in a conditions place just isn't type safe.

1 isn't type safe??

What if you (as a compiler writer) decide (how ever unlikely) that true
should for some good reasons be implemented as being 0, or bool should be
implemented as float, or something else).

That would break just about every C and C++ program in existence. Not going
to happen. The reason I used 1 was because *it could never break* and
because it has the property of being "inspectible." Inspectible means I can
look at it and know what it does without having to refer to other things.

PS No need to answer because I know this is one topic where we can't
convince you. :)

LOL, I agree with you there.

Agreed that the 'while(1)' idiom is not going anywhere, but Walter, which
would *you* write using D nowadays?

while(1) ...

or

while(true) ...

And why would you choose one form over the other?

--
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
28/02/2006 9:41:18 AM
```
Feb 27 2006
"Walter Bright" <newshound digitalmars.com> writes:
```"Derek Parnell" <derek psych.ward> wrote in message
news:14g4upyin8106\$.uuzir980l0jb.dlg 40tude.net...
Agreed that the 'while(1)' idiom is not going anywhere, but Walter, which
would *you* write using D nowadays?

while(1) ...

or

while(true) ...

And why would you choose one form over the other?

They are both equivalent. There is no technical, usability, portability,
efficiency, or aesthetic advantage to one form over the other. I'd likely
use the former simply out of habit and because it is shorter. As far as I'm
concerned, arguing about it is like arguing over if the { goes on the same
line or the next :-)

What I especially think is bad style, however, are things like:

const int forever = 1;
...
while (forever) ...

I don't see them too often, but it does happen.
```
Feb 28 2006
Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
```Walter Bright wrote:
"Derek Parnell" <derek psych.ward> wrote in message
news:14g4upyin8106\$.uuzir980l0jb.dlg 40tude.net...
Agreed that the 'while(1)' idiom is not going anywhere, but Walter, which
would *you* write using D nowadays?

while(1) ...

or

while(true) ...

And why would you choose one form over the other?

They are both equivalent. There is no technical, usability, portability,
efficiency, or aesthetic advantage to one form over the other. I'd likely
use the former simply out of habit and because it is shorter. As far as I'm

As for the usability/aesthetic advantage, it's arguable that there's no
difference. I prefer the 'true' version, as I find it more expressive,
even if the difference is not that big and while(1) doesn't bother me
that much.

concerned, arguing about it is like arguing over if the { goes on the same
line or the next :-)

Which although not a critical issue, still has some some things that
could be said about it. :D

--
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to
be... unnatural."
```
Feb 28 2006
Tom <Tom_member pathlink.com> writes:
```In article <du187e\$14bk\$4 digitaldaemon.com>, Walter Bright says...
"Derek Parnell" <derek psych.ward> wrote in message
[snip]

As far as I'm
concerned, arguing about it is like arguing over if the { goes on the same
line or the next :-)

No no no, excuse me, nobody argues that because everybody knows that '{' and '}'
goes in the next line, NEVER IN THE SAME!! :P

Sorry, I couldn't resist! :D

Tom;
```
Feb 28 2006
James Dunne <james.jdunne gmail.com> writes:
```Tom wrote:
In article <du187e\$14bk\$4 digitaldaemon.com>, Walter Bright says...

"Derek Parnell" <derek psych.ward> wrote in message

[snip]

As far as I'm
concerned, arguing about it is like arguing over if the { goes on the same
line or the next :-)

No no no, excuse me, nobody argues that because everybody knows that '{' and
'}'
goes in the next line, NEVER IN THE SAME!! :P

Sorry, I couldn't resist! :D

Tom;

Gosh I couldn't stand looking at all those wasted lines.  C# default
style is the worst, luckily I can change it in VS.Net 2003.

My vertical screen space is limited; I'd prefer getting as big a picture
as I can get on the screen at once, especially seeing as how my sight is
surely going and my fonts are getting bigger.

And spaces for indentation?  Oh please, this is what we have tab
characters for.  And why the hell do they want to stay at 8 characters
wide?  Sure this works for C code, but now we've got many more coding
practices and constructs for langauges that *require* more nesting of
branches, hence more tabs, and hence a more horizontal exspanse of code.
Nothing is wrong with your code and you simply shouldn't have to break
things up into functions.  2 is too small, 8 is too big -- 4 is just
right :)  3?  Who invited you? =P

--
Regards,
James Dunne
```
Feb 28 2006
Sean Kelly <sean f4.ca> writes:
```Walter Bright wrote:

What I especially think is bad style, however, are things like:

const int forever = 1;
...
while (forever) ...

I don't see them too often, but it does happen.

It perhaps sidesteps the issue, but I use "for(;;)" in these cases,
mostly because it avoids a constant conditional warning in VC++ :-p
"while(true)" is probably a bit more meaningful however as it's not a
counting loop.

Sean
```
Feb 28 2006
Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
```Sean Kelly wrote:
It perhaps sidesteps the issue, but I use "for(;;)" in these cases,
mostly because it avoids a constant conditional warning in VC++ :-p
"while(true)" is probably a bit more meaningful however as it's not a
counting loop.

I use that as well. It even defeats the "while (1) is shorter" argument by being
one character shorter. <g>
```
Feb 28 2006
"Derek Parnell" <derek psych.ward> writes:
```On Wed, 01 Mar 2006 04:23:00 +1100, Sean Kelly <sean f4.ca> wrote:

Walter Bright wrote:
What I especially think is bad style, however, are things like:
const int forever = 1;
...
while (forever) ...
I don't see them too often, but it does happen.

It perhaps sidesteps the issue, but I use "for(;;)" in these cases,
mostly because it avoids a constant conditional warning in VC++ :-p
"while(true)" is probably a bit more meaningful however as it's not a
counting loop.

And I remember somebody writing ..

#define forever for(;;)

. . .

forever{
. . .
}

--
Derek Parnell
Melbourne, Australia
```
Feb 28 2006
=?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
```Derek Parnell wrote:

And I remember somebody writing ..

#define forever for(;;)

. . .

forever{
. . .
}

I'm pretty sure that I saw a :

#define EVER ;;

As in: for (EVER) { young() }

--anders
```
Feb 28 2006
Sean Kelly <sean f4.ca> writes:
```Anders F BjÃ¶rklund wrote:
Derek Parnell wrote:

And I remember somebody writing ..

#define forever for(;;)

. . .

forever{
. . .
}

I'm pretty sure that I saw a :

#define EVER ;;

As in: for (EVER) { young() }

LOL

Sean
```
Feb 28 2006
James Dunne <james.jdunne gmail.com> writes:
```Derek Parnell wrote:
On Wed, 01 Mar 2006 04:23:00 +1100, Sean Kelly <sean f4.ca> wrote:

Walter Bright wrote:

What I especially think is bad style, however, are things like:
const int forever = 1;
...
while (forever) ...
I don't see them too often, but it does happen.

It perhaps sidesteps the issue, but I use "for(;;)" in these cases,
mostly because it avoids a constant conditional warning in VC++ :-p
"while(true)" is probably a bit more meaningful however as it's not a
counting loop.

And I remember somebody writing ..

#define forever for(;;)

. . .

forever{
. . .
}

It's called "Better C"

http://thedailywtf.com/forums/60255/ShowPost.aspx

/*
* BETTER_C.H
* Language refinements for C.
*/
#ifndef BETTER_C_H
#define BETTER_C_H

/* logical/comparison operators */
#define NE  !=
#define EQ  ==
#define GT  >
#define LT  <
#define GE  >=
#define LE  <=
#define AND &&
#define OR  ||
#define NOT !

/* bitwise operators */
#define bNOT ~
#define bAND &
#define bOR  |
#define bXOR ^

/* arithmetic operators */
#define MOD   %

/* control constructs */
#define repeat    do
#define until(p)  while(NOT (p))
#define forever   while(1)
#define untilbreak  forever
#define untilreturn forever
#define unless(p) if(NOT (p))
#define ifnot(p)  if(NOT (p))
#define do_nothing
#define then

...

#endif

--
Regards,
James Dunne
```
Feb 28 2006
Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
```Derek Parnell wrote:
And I remember somebody writing ..

#define forever for(;;)

. . .

forever{
. . .
}

Hey, I still think it's fun to do like I did in my early C coding days (a few
years back) and

#define EVER (;;)

and then loop

for EVER {
}
```
Mar 01 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Walter Bright wrote:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:dtuatr\$l0k\$1 digitaldaemon.com...

Walter Bright wrote:

I told you not to reply :) ...

Why? This is a practice I got into with C/C++, and I did it because 1
cannot be redefined by the preprocessor into something goofy. I.e., I
*knew* what it was without having to go spelunking through header files.

The reason should be obvious. While(condition). Condition should be
boolean (true or false). 1 is neither. It is an integer. Using 1 (or any
other int) in a conditions place just isn't type safe.

1 isn't type safe??

LOL, 1 is a perfectly safe integer, but not a safe boolean.

The code could have been while(5). Do you really think 5 is true?

What if you (as a compiler writer) decide (how ever unlikely) that true
should for some good reasons be implemented as being 0, or bool should be
implemented as float, or something else).

That would break just about every C and C++ program in existence. Not going
to happen. The reason I used 1 was because *it could never break* and
because it has the property of being "inspectible." Inspectible means I can
look at it and know what it does without having to refer to other things.

I know it isn't going to happen. To point was: this is exposing
implementation to everyone, and that is generally regarded as not a good
thing to do.

The problem in all these bool wars so far is I never saw an argument
that would be against true booleans (while(BooleanExpression) and all
that...).
The arguments like:
while(true) is much much bigger than while(1) or
while(a)    is much smaller and more understandable than while(a>0)
//hm while(a) is actually while(a!=0) but did I really mean a>0?)
and like that don't really count.

Adding true booleans makes no code break, only adds compiler errors that
make  a coder think more about what he is doing and require awfull
changes from if(b) to if(b!=0) and stop him from doing things like
adding two bools or adding an int to a bool.

PS No need to answer because I know this is one topic where we can't
convince you. :)

LOL, I agree with you there.

I still wonder why do you think that many modern and much used languages
implement real boolean types and are very proud of that? Does the
behaviour of D really fix C/C++ bool isues? Will those seeking a real
bool people not say <g> and write alias/typedef int boolean, or
something else?

I think those languages have bools because they realize bool is *not* an
int but a mathematical concept.
```
Feb 27 2006
Tom <Tom_member pathlink.com> writes:
```In article <du002m\$2pnp\$1 digitaldaemon.com>, Ivan Senji says...
Walter Bright wrote:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
Walter Bright wrote:

The problem in all these bool wars so far is I never saw an argument
that would be against true booleans (while(BooleanExpression) and all
that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I shut my
mouth forever!

Tom;
```
Feb 27 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Tom wrote:
In article <du002m\$2pnp\$1 digitaldaemon.com>, Ivan Senji says...
The problem in all these bool wars so far is I never saw an argument
that would be against true booleans (while(BooleanExpression) and all
that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I shut my
mouth forever!

LOL, So true :)
```
Feb 27 2006
Lucas Goss <lgoss007 gmail.com> writes:
```Tom wrote:
In article <du002m\$2pnp\$1 digitaldaemon.com>, Ivan Senji says...
Walter Bright wrote:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
Walter Bright wrote:

The problem in all these bool wars so far is I never saw an argument
that would be against true booleans (while(BooleanExpression) and all
that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I shut my
mouth forever!

Tom;

I don't understand this either. Just because I did things in C/C++ (I
have used while(1) quite a few times before) I don't see how this
affects D. It may be a surprise coming from C/C++, but it can't be that
hard to change while(1), to while(true).

The only argument I can see against it is existing D code that uses
while(1). But then why should progress be inhibited by past mistakes...
well I guess it's common for system languages, just look at the stuff
C/C++ has trouble fixing... :)

I'd even be willing to convert everyones D code for them... um, I hope
there aren't too many D programmers out there :)
```
Feb 27 2006
Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
```Tom skrev:
In article <du002m\$2pnp\$1 digitaldaemon.com>, Ivan Senji says...
Walter Bright wrote:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
Walter Bright wrote:

The problem in all these bool wars so far is I never saw an argument
that would be against true booleans (while(BooleanExpression) and all
that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I shut my
mouth forever!

Tom;

Does pure booleans necessarily mean that other types could not be
implicitly convertible to bool? I would love "pure" booleans (not a
numeric type, not allowed in arithmetic operations), but I would hate to
have to write:

if (a !is null || b !is null)

instead of:

if (a || b)

What is wrong with the second case? (apart from being more readable).

With such "pure" booleans, you could still write:

while(1)

With the classic definition of !0 !null implies true...

/Oskar
```
Feb 28 2006
Kyle Furlong <kylefurlong gmail.com> writes:
```Oskar Linde wrote:
Tom skrev:
In article <du002m\$2pnp\$1 digitaldaemon.com>, Ivan Senji says...
Walter Bright wrote:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
Walter Bright wrote:

The problem in all these bool wars so far is I never saw an argument
that would be against true booleans (while(BooleanExpression) and all
that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and
I shut my
mouth forever!

Tom;

Does pure booleans necessarily mean that other types could not be
implicitly convertible to bool? I would love "pure" booleans (not a
numeric type, not allowed in arithmetic operations), but I would hate to
have to write:

if (a !is null || b !is null)

instead of:

if (a || b)

I would say that the second construct is much less reliable, maintainable, and
safe than the first. Therefore, the type system
should disallow the second with a pure boolean type.

What is wrong with the second case? (apart from being more readable).

With such "pure" booleans, you could still write:

while(1)

With the classic definition of !0 !null implies true...

/Oskar

```
Feb 28 2006
Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
```Kyle Furlong skrev:
Oskar Linde wrote:
if (a !is null || b !is null)

instead of:

if (a || b)

I would say that the second construct is much less reliable,
maintainable, and safe than the first. Therefore, the type system should
disallow the second with a pure boolean type.

I have seen bugs introduced by changing

if(!a || !b)

into

if(a !is null || b !is null)

And the double negation nature of !is null makes this quite hard to spot
(for both me and the one introducing the bug). This contradicts your
saying that it makes the code "much more reliable, maintainable and
safe". Consider the sentences:

"If a or b"

compared to:

"If a is not nothing or b is not nothing"

Which one is easier to grasp and get right?

(!is also takes an extra step when it is parsed by the reader as "not
is" and then (in most western languages at least) has to be transformed
into "is not")

What do you base your statements on? Do you have examples of where
(a||b) is less reliable or less safe? Why would it be less maintainable?
It is clearer (less complex) an has a well defined semantic meaning.

JMHO

/Oskar
```
Feb 28 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Oskar Linde wrote:
Kyle Furlong skrev:

Oskar Linde wrote:

if (a !is null || b !is null)

instead of:

if (a || b)

I would say that the second construct is much less reliable,
maintainable, and safe than the first. Therefore, the type system
should disallow the second with a pure boolean type.

I have seen bugs introduced by changing

if(!a || !b)

into

if(a !is null || b !is null)

I would argue that the bug in the first place is coding something like
!a || ! b.

And the double negation nature of !is null makes this quite hard to spot
(for both me and the one introducing the bug). This contradicts your
saying that it makes the code "much more reliable, maintainable and
safe". Consider the sentences:

Ok lets add some values to a sentence... (let's say a and b are pointers)

"If a or b"

if 0x01233d3f or 0x533123ff

What does that mean in any human language? Exactly nothing!

compared to:

"If a is not nothing or b is not nothing"

if 0x01233d3f isn't 0x00000000 or 0x533123ff isn't 0x00000000

Which one is easier to grasp and get right?

The second one, obviously. The first one has no meaning, second one has
obvious and clear meaning, so there is no realy question here...

(!is also takes an extra step when it is parsed by the reader as "not
is" and then (in most western languages at least) has to be transformed
into "is not")

I don't see that as souch a big problem.
And if you think it is the same problem in if(!a || !b).
I read it like if not a or not b, and I have to ask myself what not a?
a not an elephant? not an apple? not an integer? not null? not not null?

What do you base your statements on? Do you have examples of where
(a||b) is less reliable or less safe? Why would it be less maintainable?

(a||b) is an example of that :)

It is clearer (less complex) an has a well defined semantic meaning.

It is more complex an doesn't have a well defined semantic meaning.
I mean Walter says it does, but the argument 1 is true in C, isn't
really an argument. Why then do we have GC, delegates, templates,
why then do we have type safety after all? Why out/inout when everything
can be done with pointers...

It is that way in C shouldn't be an exceptable argument for otherwise
superb language like D. (IMHO)
```
Feb 28 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Kyle Furlong wrote:
Oskar Linde wrote:

Tom skrev:

In article <du002m\$2pnp\$1 digitaldaemon.com>, Ivan Senji says...

Walter Bright wrote:

"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message

Walter Bright wrote:

The problem in all these bool wars so far is I never saw an argument
that would be against true booleans (while(BooleanExpression) and
all that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and
I shut my
mouth forever!

Tom;

Does pure booleans necessarily mean that other types could not be
implicitly convertible to bool? I would love "pure" booleans (not a
numeric type, not allowed in arithmetic operations), but I would hate
to have to write:

if (a !is null || b !is null)

instead of:

if (a || b)

I would say that the second construct is much less reliable,
maintainable, and safe than the first. Therefore, the type system should
disallow the second with a pure boolean type.

Ah, you can't explain that to a nonbeliever. :)
```
Feb 28 2006
Don Clugston <dac nospam.com.au> writes:
```Oskar Linde wrote:
Tom skrev:
In article <du002m\$2pnp\$1 digitaldaemon.com>, Ivan Senji says...
Walter Bright wrote:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
Walter Bright wrote:

The problem in all these bool wars so far is I never saw an argument
that would be against true booleans (while(BooleanExpression) and all
that...).

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and
I shut my
mouth forever!

Tom;

Does pure booleans necessarily mean that other types could not be
implicitly convertible to bool? I would love "pure" booleans (not a
numeric type, not allowed in arithmetic operations), but I would hate to
have to write:

if (a !is null || b !is null)

I agree. I think implicit bool in conditionals is important,
but in assignments its almost always a bug.

eg
bool b=false;
b++;  // either this is hiding a bug, or it's a really confusing way of
expressing what you want.

In a conditional, there's an implicit "!is null" at the end of every
expression. That's why || is not the same as |.
This is not the same as implicit conversion from int to bool.
And bool-> int is a particularly troublesome conversion.

bool b;
int x = b;
This IS a mistake that I often make (eg, I typed 'b' when it should have
been 'c').

Seems to me, that the useful cases Walter keeps talking about (and which
I use all the time) can be accommodated, while still catching the sloppy
thinking and type mismatch bugs where you get genuine benefit from pure
bools.
```
Feb 28 2006
"Walter Bright" <newshound digitalmars.com> writes:
```"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I
shut my
mouth forever!

One should be very careful about stepping away from C's implicit promotion
rules for a language that aims to be a successor to C. C absolutely *buried*
Pascal.

Pascal didn't have implicit type conversions. That meant that typical Pascal
code was littered with casts. It was ugly, and I'd argue that casting
reduces type safety, rather than enhancing it.

Pascal played catchup ever since, adopting features of C. Then Pascal++
(i.e. Modula 2) came out, which was promptly buried by C++.
```
Feb 28 2006
Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
```Walter Bright skrev:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I
shut my
mouth forever!

One should be very careful about stepping away from C's implicit promotion
rules for a language that aims to be a successor to C. C absolutely *buried*
Pascal.

I agree. I also find while(5) to be perfectly acceptable. But the
problem with placing bool in the integer promotion chain is that it has
a semantic difference to the other integer types.

- cast from a larger type to bool is defined as x != 0, rater than the
analogue of (x&1) for the other integer types.

This gives bool slightly different arithmetic properties as I mentioned
in a very lengthy post in another place in this thread.
(news://news.digitalmars.com:119/dtv65q\$1ps2\$1 digitaldaemon.com)

One such property is the asymmetry: bool never overflows but does
underflow. (a++ sets a to true, while a-- flips a's truth value).

Another reason not to place bool among the other integer types is that
many people expect a bool to be semantically different from integer types.

For instance, if you know about boolean algebra, you would expect a+b to
be evaluated as a or b... And it is -- almost. The integer promotion
unfortunately makes comparisons of truth values shaky (assume a,b boolean):

(a+b == true) // here, + becomes xor!

vs:

bool x = a+b; // here, + behaves as or

If bools where removed from the integer promotion chain, the problem
with "== true" would go away. Forever. :)

/Oskar
```
Feb 28 2006
Tom <Tom_member pathlink.com> writes:
```In article <du19j7\$15r9\$2 digitaldaemon.com>, Walter Bright says...
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I
shut my
mouth forever!

One should be very careful about stepping away from C's implicit promotion
rules for a language that aims to be a successor to C. C absolutely *buried*
Pascal.

So it's because you think that leaving C bools has more "marketing" and would
achieve more "popularity" among future D coders (and most of all, C coders)?
Or is it because you don't want C users to feel uncomfortable with D?
Just to be a succesor doesn't mean that you can't change the rules, in fact you
changed a lot of them so that D compiler isn't a C compiler.
OTOH I'm a C coder as well as coder of another languages, and I would asure you
that pure boolean consequences wouldn't bother me at all.

Pascal didn't have implicit type conversions. That meant that typical Pascal
code was littered with casts. It was ugly, and I'd argue that casting
reduces type safety, rather than enhancing it.

Ok, so pure booleans would end in this kind of cast invasion? If this was the
case (which I can't see right now), then I would totally understand you leave
bool as it is. But if I can recall someone said in another post, languages as C#
has pure booleans implemented: I don't see people crying about C# because of it.
It's becomming tremendously popular in fact!

Pascal played catchup ever since, adopting features of C. Then Pascal++
(i.e. Modula 2) came out, which was promptly buried by C++.

I agree that Pascal is dead but don't see D as a future Pascal at all, no matter
if it has pure booleans or not. :)

As a final thought I realize that this bool fight has more taste-related
arguments to defend each position than pragmatic ones. So we WON'T convince
Walter 'cos it would be a matter of trying to change people tastes. We know that
this is IMPOSSIBLE ;)

Thanks for the answers,

Tom;
```
Feb 28 2006
"Derek Parnell" <derek psych.ward> writes:
```On Tue, 28 Feb 2006 21:42:59 +1100, Walter Bright
<newshound digitalmars.com> wrote:

"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I
shut my
mouth forever!

One should be very careful about stepping away from C's implicit
promotion
rules for a language that aims to be a successor to C. C absolutely
*buried*
Pascal.

Pascal didn't have implicit type conversions. That meant that typical
Pascal
code was littered with casts. It was ugly, and I'd argue that casting
reduces type safety, rather than enhancing it.

Pascal played catchup ever since, adopting features of C. Then Pascal++
(i.e. Modula 2) came out, which was promptly buried by C++.

How would disallowing arithmetic on bools make D like Pascal, or bring
about the "littered with casts" scenerio? I just can't see it would change
a thing, except help the compiler help coders detect possible errors in
their code.

--
Derek Parnell
Melbourne, Australia
```
Feb 28 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Walter Bright wrote:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...

Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I
shut my
mouth forever!

One should be very careful about stepping away from C's implicit promotion
rules for a language that aims to be a successor to C. C absolutely *buried*
Pascal.

I don't feel like writing any more about this: but here goes one more...
:)

Did you read posts by Tom and Derek? I completely agree with them. I
came from Pascal to C(actually C++), and there is *no* way for D to
become Pascal. No way even if that strange C-like bools are removed and
replaced with a more modern bool type.

Stepping away from C on this bool story would only encourage everyone to
move to D, sticking with C these days isn't a great attractor for
C++/Java/C# and probably most other users.

on_scope might me an important feature but it isn't the first feature a
new user will meet. A new user is likely to encounter bool first, be
dissapointed and run away before finding all other cool features. (IMO)

Pascal didn't have implicit type conversions. That meant that typical Pascal
code was littered with casts. It was ugly, and I'd argue that casting
reduces type safety, rather than enhancing it.

Sure if you have to do it all the time, I agree with most implicit
conversions that D has, but not about those for bool.
```
Feb 28 2006
Carlos Santander <csantander619 gmail.com> writes:
```Walter Bright escribió:

One should be very careful about stepping away from C's implicit promotion
rules for a language that aims to be a successor to C. C absolutely *buried*
Pascal.

Pascal didn't have implicit type conversions. That meant that typical Pascal
code was littered with casts. It was ugly, and I'd argue that casting
reduces type safety, rather than enhancing it.

Pascal played catchup ever since, adopting features of C. Then Pascal++
(i.e. Modula 2) came out, which was promptly buried by C++.

That depends on how you code and what you code. I recently wrote a 1600+ LOC
Pascal program and I never used a single cast, just because I never needed one.
So, that argument is not very strong because it depends on the nature of each
situation.

--
Carlos Santander Bernal
```
Feb 28 2006
Roberto Mariottini <Roberto_member pathlink.com> writes:
```In article <du19j7\$15r9\$2 digitaldaemon.com>, Walter Bright says...
Pascal didn't have implicit type conversions. That meant that typical Pascal
code was littered with casts. It was ugly, and I'd argue that casting
reduces type safety, rather than enhancing it.

This is untrue. Pascal is a strong-typed language for application programming,
so you won't need a single cast (something in Pascal doesn't exist).
Pascal was not born for system programming, for this at the time people used
assembly (O.S. themselves were writeen in assembly).

Pascal played catchup ever since, adopting features of C. Then Pascal++
(i.e. Modula 2) came out, which was promptly buried by C++.

This is pathethic.

When ISO Pascal standard was issued, there wasn't an ISO C.
The first ANSI C is from 1989, six years after the Pascal standard.
And ANSI-C was a very different language from pre-ANSI-C, for example
introducing function prototypes, and changing the function argument passing
behaviour, among the other things. So it' *C that has adopted features of
Pascal* not the reverse.

It's funny that you say that Modula-2 took something from C++, that is not the
case.
D took modules from Modula-2, instead, and better than the loosy C++ namespace
thing.

Ciao

P.S.: A little time table:

1970 The first Pascal compiler is released
1973 The first Unix kernel is written in C (with the first C compiler available)
1974 The book "PASCAL - User Manual and Report" is published
1978 The book "The C Programming Language" by K&R is published
1980 The first Modula-2 compiler is released
1982 The book "Programming in Modula-2" is published
1983 The ISO Pascal standard is approved
1985 The first edition of "The C++ Programming Language" and the first C++
compiler are released
1989 The ANSI/ISO C standard is approved
1996 The ISO Modula-2 standard is approved
1998 The ISO C++ standard is approved

As you can see the first Pascal compiler predates the first C compiler, the
first Modula-2 compiler predates the first C++ compiler, Pascal predates C and
Modula-2 predates C++.

References:
http://en.wikipedia.org/wiki/Pascal_programming_language
http://en.wikipedia.org/wiki/Modula-2
http://www.cs.inf.ethz.ch/~wirth/

http://en.wikipedia.org/wiki/C_language
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
http://en.wikipedia.org/wiki/C%2B%2B
```
Mar 01 2006
Tom <Tom_member pathlink.com> writes:
```In article <du3vu2\$6ng\$1 digitaldaemon.com>, Roberto Mariottini says...
In article <du19j7\$15r9\$2 digitaldaemon.com>, Walter Bright says...

Pascal played catchup ever since, adopting features of C. Then Pascal++
(i.e. Modula 2) came out, which was promptly buried by C++.

It's funny that you say that Modula-2 took something from C++, that is not the
case.

Mmmh? Or I'm totally wasted or Walter didn't say that?

Tom;
"Pure Boolean Rules!" :D
```
Mar 01 2006
Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
```Walter Bright wrote:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I
shut my
mouth forever!

One should be very careful about stepping away from C's implicit promotion
rules for a language that aims to be a successor to C. C absolutely *buried*
Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you
meant by "C's implicit promotion rules" (as C doesn't even have a bool).
But ok, nevermind, let's pause for a moment, and get our facts straight.

What exactly is it in bools that you Walter, want and not want?
I already know that the ability to write 'while(1)' as the same as
'while(true)' is one of them, but, anything more?
Is the behaviour of having an "implicit promotion" something you want too?
If so, promotion from where, from int to bool, or from bool to int?
Do you want or not want bool numeric operations to be an error (like
boolA / boolB*2) ?

--
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to
be... unnatural."
```
Mar 02 2006
Don Clugston <dac nospam.com.au> writes:
```Bruno Medeiros wrote:
Walter Bright wrote:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and
I shut my
mouth forever!

One should be very careful about stepping away from C's implicit
promotion rules for a language that aims to be a successor to C. C
absolutely *buried* Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you
meant by "C's implicit promotion rules" (as C doesn't even have a bool).
But ok, nevermind, let's pause for a moment, and get our facts straight.

What exactly is it in bools that you Walter, want and not want?
I already know that the ability to write 'while(1)' as the same as
'while(true)' is one of them, but, anything more?
Is the behaviour of having an "implicit promotion" something you want too?
If so, promotion from where, from int to bool, or from bool to int?
Do you want or not want bool numeric operations to be an error (like
boolA / boolB*2) ?

I think one use case that is important is to be able to use bool to
connect to C APIs (such as the Windows SDK) that use BOOL (a short).

Interestingly, you only need this for extern(C), extern(Windows)
declarations. It would be fantastic if there was a way to specify that
an extern function is actually a synthetic bool.

The ability to say
if (p || q) {}
instead of
if (p !is null || q !is null) {}
is important too.

I too would like to know if Walter has more.
```
Mar 02 2006
Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
```Don Clugston wrote:
Bruno Medeiros wrote:
Walter Bright wrote:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one
and I shut my
mouth forever!

One should be very careful about stepping away from C's implicit
promotion rules for a language that aims to be a successor to C. C
absolutely *buried* Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what
you meant by "C's implicit promotion rules" (as C doesn't even have a
bool). But ok, nevermind, let's pause for a moment, and get our facts
straight.

What exactly is it in bools that you Walter, want and not want?
I already know that the ability to write 'while(1)' as the same as
'while(true)' is one of them, but, anything more?
Is the behaviour of having an "implicit promotion" something you want
too?
If so, promotion from where, from int to bool, or from bool to int?
Do you want or not want bool numeric operations to be an error (like
boolA / boolB*2) ?

I think one use case that is important is to be able to use bool to
connect to C APIs (such as the Windows SDK) that use BOOL (a short).

Don't hamper D because of that. Better solution then is to keep that
separate from D's bool, no? :
alias BOOL short.

--
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to
be... unnatural."
```
Mar 03 2006
Tom <Tom_member pathlink.com> writes:
```In article <du71jc\$1e9h\$1 digitaldaemon.com>, Bruno Medeiros says...
Walter Bright wrote:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I
shut my
mouth forever!

One should be very careful about stepping away from C's implicit promotion
rules for a language that aims to be a successor to C. C absolutely *buried*
Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you
meant by "C's implicit promotion rules" (as C doesn't even have a bool).
But ok, nevermind, let's pause for a moment, and get our facts straight.

What exactly is it in bools that you Walter, want and not want?
I already know that the ability to write 'while(1)' as the same as
'while(true)' is one of them, but, anything more?
Is the behaviour of having an "implicit promotion" something you want too?
If so, promotion from where, from int to bool, or from bool to int?
Do you want or not want bool numeric operations to be an error (like
boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with subject "Re:
DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist
kind* of boolean type. A boolean type that abstracts us from the implementation.

Tom;
```
Mar 02 2006
Don Clugston <dac nospam.com.au> writes:
```Tom wrote:
In article <du71jc\$1e9h\$1 digitaldaemon.com>, Bruno Medeiros says...
Walter Bright wrote:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one and I
shut my
mouth forever!

One should be very careful about stepping away from C's implicit promotion
rules for a language that aims to be a successor to C. C absolutely *buried*
Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what you
meant by "C's implicit promotion rules" (as C doesn't even have a bool).
But ok, nevermind, let's pause for a moment, and get our facts straight.

What exactly is it in bools that you Walter, want and not want?
I already know that the ability to write 'while(1)' as the same as
'while(true)' is one of them, but, anything more?
Is the behaviour of having an "implicit promotion" something you want too?
If so, promotion from where, from int to bool, or from bool to int?
Do you want or not want bool numeric operations to be an error (like
boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with subject "Re:
DMD 0.148 release"). It's all said there. By "pure bools" I mean the *purist
kind* of boolean type. A boolean type that abstracts us from the
implementation.

Sorry, that's still not clear.
Bruno is right, terms like "pure bools" or "purist bools" are vague, you
can't expect everyone to know what you mean.

For example: do you want "&" to be legal for bool types, or just "&&"?
(they mean very different things for integers). "&" normally means
"bitwise and", but a pure bool doesn't have any bits.
Is it legal to cast from a bool to some other type?

A boolean type that abstracts us from the implementation.

No abstraction is perfect. Does a bool have a defined bit
representation? (If you say 'no' to this, then I don't think a bool
could be used in an extern function, you'd always have to convert it to
int or something).

You need a comprehensive list of which operations are legal, and which
are not.
```
Mar 03 2006
Kyle Furlong <kylefurlong gmail.com> writes:
```Don Clugston wrote:
Tom wrote:
In article <du71jc\$1e9h\$1 digitaldaemon.com>, Bruno Medeiros says...
Walter Bright wrote:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one
and I shut my
mouth forever!

One should be very careful about stepping away from C's implicit
promotion rules for a language that aims to be a successor to C. C
absolutely *buried* Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what
you meant by "C's implicit promotion rules" (as C doesn't even have a
bool). But ok, nevermind, let's pause for a moment, and get our facts
straight.

What exactly is it in bools that you Walter, want and not want?
I already know that the ability to write 'while(1)' as the same as
'while(true)' is one of them, but, anything more?
Is the behaviour of having an "implicit promotion" something you want
too?
If so, promotion from where, from int to bool, or from bool to int?
Do you want or not want bool numeric operations to be an error (like
boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with
subject "Re:
DMD 0.148 release"). It's all said there. By "pure bools" I mean the
*purist
kind* of boolean type. A boolean type that abstracts us from the
implementation.

Sorry, that's still not clear.
Bruno is right, terms like "pure bools" or "purist bools" are vague, you
can't expect everyone to know what you mean.

For example: do you want "&" to be legal for bool types, or just "&&"?
(they mean very different things for integers). "&" normally means
"bitwise and", but a pure bool doesn't have any bits.
Is it legal to cast from a bool to some other type?

> A boolean type that abstracts us from the implementation.

No abstraction is perfect. Does a bool have a defined bit
representation? (If you say 'no' to this, then I don't think a bool
could be used in an extern function, you'd always have to convert it to
int or something).

You need a comprehensive list of which operations are legal, and which
are not.

I tend to want a boolean that is an operand of the boolean algebra and nothing
else. So it is either true or false, independant
of implementation, integer operations are illegal, and it cant be cast to
anything.
```
Mar 03 2006
Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
```Don Clugston wrote:
Tom wrote:
In article <du71jc\$1e9h\$1 digitaldaemon.com>, Bruno Medeiros says...
Walter Bright wrote:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one
and I shut my
mouth forever!

One should be very careful about stepping away from C's implicit
promotion rules for a language that aims to be a successor to C. C
absolutely *buried* Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what
you meant by "C's implicit promotion rules" (as C doesn't even have a
bool). But ok, nevermind, let's pause for a moment, and get our facts
straight.

What exactly is it in bools that you Walter, want and not want?
I already know that the ability to write 'while(1)' as the same as
'while(true)' is one of them, but, anything more?
Is the behaviour of having an "implicit promotion" something you want
too?
If so, promotion from where, from int to bool, or from bool to int?
Do you want or not want bool numeric operations to be an error (like
boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with
subject "Re:
DMD 0.148 release"). It's all said there. By "pure bools" I mean the
*purist
kind* of boolean type. A boolean type that abstracts us from the
implementation.

Sorry, that's still not clear.
Bruno is right, terms like "pure bools" or "purist bools" are vague, you
can't expect everyone to know what you mean.

For example: do you want "&" to be legal for bool types, or just "&&"?
(they mean very different things for integers). "&" normally means
"bitwise and", but a pure bool doesn't have any bits.
Is it legal to cast from a bool to some other type?

> A boolean type that abstracts us from the implementation.

No abstraction is perfect. Does a bool have a defined bit
representation? (If you say 'no' to this, then I don't think a bool
could be used in an extern function, you'd always have to convert it to
int or something).

You need a comprehensive list of which operations are legal, and which
are not.

Exactly, the "pure bools" must be defined by a set of language
behaviors. Derek made a post some time ago with one such definition
(news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg 40tude.net).

However, the problem is, and the reason I opened this thread, that in
the previous discussion people started getting lost in a too vague or
incongruous debate of "pure bools" vs. being able to use "while(1)" and
implicit conversions and whatnot (arguing about things that are not on
the same level).
What I'm trying to say is, that of that set of bool behaviors, it is not
an all or nothing situation, it is a gradient of behaviors. Just a part
of them can be implemented, and if all Walter wants is the ability to do
"while(1)" or 'implicit conversion of integers to bool' (which are the
only counter-points I've seen so far), then there is still a lot of
other things that can me made to improve bool:

We could have:
* Conditional expressions should be of type bool
* Integers can be implicitly converted to bool, as Walter wants. (where
0 is false, the rest is true). This allows for "while(1)" .
* Pointer and references can be implicitly converted too (where null is
false, the rest is true). This allows for "if(objFoo)" .
* No numeric operations are allowed on bool, just boolean operations.
* bool can only be explicitly cast to a numeric type.
* Regardless of bool implementation, it has only two abstract states:
true or false, and conversions from int should be aware of that. For
instance this should 'then':
if (2==true) writefln("then");  // doesnt "then" :(

It won't be the "purest" of bools (like Java or C# or other languages),
because of the second feature, but it's still a lot better than what we
have. Walter what's your take? Do you have any problem with any of these
behaviors?

--
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to
be... unnatural."
```
Mar 03 2006
Tom <Tom_member pathlink.com> writes:
```In article <du9cnl\$2h9j\$3 digitaldaemon.com>, Bruno Medeiros says...
Don Clugston wrote:
Tom wrote:
In article <du71jc\$1e9h\$1 digitaldaemon.com>, Bruno Medeiros says...
Walter Bright wrote:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one
and I shut my
mouth forever!

One should be very careful about stepping away from C's implicit
promotion rules for a language that aims to be a successor to C. C
absolutely *buried* Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what
you meant by "C's implicit promotion rules" (as C doesn't even have a
bool). But ok, nevermind, let's pause for a moment, and get our facts
straight.

What exactly is it in bools that you Walter, want and not want?
I already know that the ability to write 'while(1)' as the same as
'while(true)' is one of them, but, anything more?
Is the behaviour of having an "implicit promotion" something you want
too?
If so, promotion from where, from int to bool, or from bool to int?
Do you want or not want bool numeric operations to be an error (like
boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with
subject "Re:
DMD 0.148 release"). It's all said there. By "pure bools" I mean the
*purist
kind* of boolean type. A boolean type that abstracts us from the
implementation.

Sorry, that's still not clear.
Bruno is right, terms like "pure bools" or "purist bools" are vague, you
can't expect everyone to know what you mean.

[snip]

Derek made a post some time ago with one such definition
(news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg 40tude.net).

And that is exactly what I meant when I said that you should read the latest
posts on the stuff :)

Tom;
```
Mar 03 2006
Don Clugston <dac nospam.com.au> writes:
```Tom wrote:
In article <du9cnl\$2h9j\$3 digitaldaemon.com>, Bruno Medeiros says...
Don Clugston wrote:
Tom wrote:
In article <du71jc\$1e9h\$1 digitaldaemon.com>, Bruno Medeiros says...
Walter Bright wrote:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one
and I shut my
mouth forever!

One should be very careful about stepping away from C's implicit
promotion rules for a language that aims to be a successor to C. C
absolutely *buried* Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what
you meant by "C's implicit promotion rules" (as C doesn't even have a
bool). But ok, nevermind, let's pause for a moment, and get our facts
straight.

What exactly is it in bools that you Walter, want and not want?
I already know that the ability to write 'while(1)' as the same as
'while(true)' is one of them, but, anything more?
Is the behaviour of having an "implicit promotion" something you want
too?
If so, promotion from where, from int to bool, or from bool to int?
Do you want or not want bool numeric operations to be an error (like
boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with
subject "Re:
DMD 0.148 release"). It's all said there. By "pure bools" I mean the
*purist
kind* of boolean type. A boolean type that abstracts us from the
implementation.

Sorry, that's still not clear.
Bruno is right, terms like "pure bools" or "purist bools" are vague, you
can't expect everyone to know what you mean.

[snip]

Derek made a post some time ago with one such definition
(news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg 40tude.net).

And that is exactly what I meant when I said that you should read the latest
posts on the stuff :)

And if you read that post, you will find that Derek said:

** It can be explicitly cast to an integer such that false is 0, and
true is 1.

whereas Kyle said:

integer operations are illegal, and it cant be cast to anything.

So there are at least four types of bool being discussed. Probably more.
And at least two can be called "pure bool".
(a) the existing bool
(b) Bruno and I are in here somewhere, and are not necessarily the same.
(c) Derek
(d) Kyle

Right now, (a) and (c) are the only ones which are clearly defined.
```
Mar 03 2006
xs0 <xs0 xs0.com> writes:
```Don Clugston wrote:
Tom wrote:
In article <du9cnl\$2h9j\$3 digitaldaemon.com>, Bruno Medeiros says...
Don Clugston wrote:
Tom wrote:
In article <du71jc\$1e9h\$1 digitaldaemon.com>, Bruno Medeiros says...
Walter Bright wrote:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only
one and I shut my
mouth forever!

One should be very careful about stepping away from C's implicit
promotion rules for a language that aims to be a successor to C.
C absolutely *buried* Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure
what you meant by "C's implicit promotion rules" (as C doesn't
even have a bool). But ok, nevermind, let's pause for a moment,
and get our facts straight.

What exactly is it in bools that you Walter, want and not want?
I already know that the ability to write 'while(1)' as the same as
'while(true)' is one of them, but, anything more?
Is the behaviour of having an "implicit promotion" something you
want too?
If so, promotion from where, from int to bool, or from bool to int?
Do you want or not want bool numeric operations to be an error
(like boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with
subject "Re:
DMD 0.148 release"). It's all said there. By "pure bools" I mean
the *purist
kind* of boolean type. A boolean type that abstracts us from the
implementation.

Sorry, that's still not clear.
Bruno is right, terms like "pure bools" or "purist bools" are vague,
you can't expect everyone to know what you mean.

[snip]

Derek made a post some time ago with one such definition
(news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg 40tude.net).

And that is exactly what I meant when I said that you should read the
latest
posts on the stuff :)

And if you read that post, you will find that Derek said:

** It can be explicitly cast to an integer such that false is 0, and
true is 1.

whereas Kyle said:

integer operations are illegal, and it cant be cast to anything.

So there are at least four types of bool being discussed. Probably more.
And at least two can be called "pure bool".
(a) the existing bool
(b) Bruno and I are in here somewhere, and are not necessarily the same.
(c) Derek
(d) Kyle

Right now, (a) and (c) are the only ones which are clearly defined.

Hmm, how about an expansion of (d):

1) still allow implicit casts to bool from any type, as in
- value != 0
- obj_ref !is null
- pointer !is null
- array.ptr !is null
- !struct.opEquals(0) // does this work now?

2) forbid casts from bool to anything else (even explicit; besides
"foo?1:0" is shorter and more obvious than "cast(int)foo")

3) when an expression involves a bool operand, all other operands get
converted to bool

4) forbid all operators on bools, except ==, !=, &&, ||, &, |, and !. (&
and | don't short-circuit evaluation, but are otherwise equivalent to &&
and ||).

Then, the purists should be satisfied, because the only operations
allowed are the logic ones, and true and false don't have a numeric
representation.

There is a true/false representation of everything else, though,
allowing all the short forms we like, like

while(1)
if (foo && foo.bar())
if (refA || refB)

xs0
```
Mar 03 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```xs0 wrote:

Hmm, how about an expansion of (d):

1) still allow implicit casts to bool from any type, as in
- value != 0
- obj_ref !is null
- pointer !is null
- array.ptr !is null
- !struct.opEquals(0) // does this work now?

2) forbid casts from bool to anything else (even explicit; besides
"foo?1:0" is shorter and more obvious than "cast(int)foo")

3) when an expression involves a bool operand, all other operands get
converted to bool

4) forbid all operators on bools, except ==, !=, &&, ||, &, |, and !. (&
and | don't short-circuit evaluation, but are otherwise equivalent to &&
and ||).

Then, the purists should be satisfied, because the only operations
allowed are the logic ones, and true and false don't have a numeric
representation.

Ok, I (as a bool purist) will not be satisfied with that & and | part.
& and | are not logic operations but bit operations.

There is a true/false representation of everything else, though,
allowing all the short forms we like, like

while(1)
if (foo && foo.bar())
if (refA || refB)

Yuck, but I would agree with it as long as conditions have to be
booleans. I know it isn't a perfect world and although I would never use
the above, it would still be better than what we have now (as long as
all the other conditions are satisified).
```
Mar 03 2006
xs0 <xs0 xs0.com> writes:
```Ivan Senji wrote:
xs0 wrote:
4) forbid all operators on bools, except ==, !=, &&, ||, &, |, and !.
(& and | don't short-circuit evaluation, but are otherwise equivalent
to && and ||).

Then, the purists should be satisfied, because the only operations
allowed are the logic ones, and true and false don't have a numeric
representation.

Ok, I (as a bool purist) will not be satisfied with that & and | part.
& and | are not logic operations but bit operations.

They are bitwise operations on integers, because that's what they're
defined to be. We're free to define them to do something else on
booleans, which I propose to be [what I said above].

BTW, even Java, which has a really purist boolean implementation, uses
those for exactly the stated purpose (and even calls them "logical
operators", while && and || are "conditional-and" and "-or" :)

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.5

There is a true/false representation of everything else, though,
allowing all the short forms we like, like

while(1)
if (foo && foo.bar())
if (refA || refB)

Yuck, but I would agree with it as long as conditions have to be
booleans. I know it isn't a perfect world and although I would never use
the above, it would still be better than what we have now (as long as
all the other conditions are satisified).

I used to think so too, until I was forced to code in Java :) Even
though I don't mind typing something as simple as

if (a!=null)

the verbosity of longer expressions really annoys the heck out of me.
Now, I prefer

if (a && b && c && d) // check for nulls
...

to

if (a!=null && b!=null && c!=null && d!=null)
...

or D's even verboser

if (a !is null && b !is null && c !is null || d !is null)
...

Note how the vars that are being tested get lost in there.. BTW, did you
notice the last line is not equivalent? :)

xs0
```
Mar 03 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```xs0 wrote:
They are bitwise operations on integers, because that's what they're
defined to be. We're free to define them to do something else on
booleans, which I propose to be [what I said above].

Ok, now I understand what you're saying. But to have that behaviour we
need very very different bools.

BTW, even Java, which has a really purist boolean implementation, uses
those for exactly the stated purpose (and even calls them "logical
operators", while && and || are "conditional-and" and "-or" :)

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.5

Thanks for the link.

There is a true/false representation of everything else, though,
allowing all the short forms we like, like

while(1)
if (foo && foo.bar())
if (refA || refB)

Yuck, but I would agree with it as long as conditions have to be
booleans. I know it isn't a perfect world and although I would never
use the above, it would still be better than what we have now (as long
as all the other conditions are satisified).

I used to think so too, until I was forced to code in Java :)

I also coded in Java and never found this to be a problem :)

Even though I don't mind typing something as simple as

if (a!=null)

the verbosity of longer expressions really annoys the heck out of me.
Now, I prefer

> if (a && b && c && d) // check for nulls

But what is going on behind the scene if a,b,c,d are ints or ponters,
conversions to bools? I still don't get it how logic && operator can be
aplied to integers. What is 5 && 3? (Except two numbers: 5,3.) It has no
value regarding truth. It is neither true nor false.

>    ...

to

> if (a!=null && b!=null && c!=null && d!=null)

better.... :)

>    ...

or D's even verboser

> if (a !is null && b !is null && c !is null || d !is null)

the best :)

Except that little bug caused deliberately by you :)

Formated this way:

if( (a !is null) && (b !is null) && (c !is null) && (d !is null) )

it is alittle bit more clear.
```
Mar 03 2006
xs0 <xs0 xs0.com> writes:
```Ivan Senji wrote:
xs0 wrote:

I used to think so too, until I was forced to code in Java :)

I also coded in Java and never found this to be a problem :)

Sure, it has an easy "workaround", but like I said, I don't think the
added verbosity helps, rather the opposite.

Even though I don't mind typing something as simple as

if (a!=null)

the verbosity of longer expressions really annoys the heck out of me.
Now, I prefer

> if (a && b && c && d) // check for nulls

But what is going on behind the scene if a,b,c,d are ints or ponters,
conversions to bools? I still don't get it how logic && operator can be
aplied to integers. What is 5 && 3? (Except two numbers: 5,3.) It has no
value regarding truth. It is neither true nor false.

Well, I believe that is just a matter of education/documentation. As
much as you need to know that && will short-circuit, you also need to
know that it will evaluate the operands as booleans. And, while 3 or 5
are definitely neither true nor false in themselves, one can certainly
define a conversion between them and booleans..

It's somewhat like Java's evaluation of "abc"+123. It's implied that 123
will be converted to a string form, and no-one seems to mind, even
though there is no implicit relationship between numbers and strings
(no, there isn't; 123 as a string could just as easily be "321"(*) or
"123.0000000000000", "onetwothree" or "WARNING: auto-conversion of 123
of type int to java.lang.String").. Would you also prefer

"abc"+String.valueOf(123)

or even

// hey, who ever heard of a sum of strings?
StringBuffer sb=new StringBuffer();
sb.append("abc");
sb.append(123);
return sb.toString();

?

I mean, compared to almost everything else in programming, is it really
so hard to grasp/learn/remember/know/whatever that 0 and null evaluate
to false, while everything else evaluates to true?

xs0

*) this could be called a little-endian string :)
```
Mar 06 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```xs0 wrote:
Well, I believe that is just a matter of education/documentation. As
much as you need to know that && will short-circuit, you also need to
know that it will evaluate the operands as booleans. And, while 3 or 5
are definitely neither true nor false in themselves, one can certainly
define a conversion between them and booleans..

Sure, only question: does it makes sense to do that? Judging by the
mayority of opinions it does make sense.

It's somewhat like Java's evaluation of "abc"+123. It's implied that 123
will be converted to a string form, and no-one seems to mind, even
though there is no implicit relationship between numbers and strings
(no, there isn't; 123 as a string could just as easily be "321"(*) or
"123.0000000000000", "onetwothree" or "WARNING: auto-conversion of 123
of type int to java.lang.String").. Would you also prefer

"abc"+String.valueOf(123)

it could be like in C#(if I remember correctly): "abc" + 123.ToString();
Well i certainly don't miss this aspect of Java in D. There is a good
way (maybe a little longer) to do that in D.

or even

// hey, who ever heard of a sum of strings?
StringBuffer sb=new StringBuffer();
sb.append("abc");
sb.append(123);
return sb.toString();

?

No I wouldn't prefer these.
I prefer format("abc",123); :)

I mean, compared to almost everything else in programming, is it really
so hard to grasp/learn/remember/know/whatever that 0 and null evaluate
to false, while everything else evaluates to true?

No, the problem is and never was in neither grasping nor learning nor
remembering this behavior. The problem was that some people see booleans
as mathematicians, and in math bools can only be true or false, and can
only be a result of operations like <,==,>=, !is, ...

xs0

*) this could be called a little-endian string :)

Cool!
```
Mar 06 2006
Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
```xs0 wrote:
Don Clugston wrote:
And if you read that post, you will find that Derek said:

** It can be explicitly cast to an integer such that false is 0, and
true is 1.

whereas Kyle said:

integer operations are illegal, and it cant be cast to anything.

So there are at least four types of bool being discussed. Probably more.
And at least two can be called "pure bool".
(a) the existing bool
(b) Bruno and I are in here somewhere, and are not necessarily the same.
(c) Derek
(d) Kyle

Right now, (a) and (c) are the only ones which are clearly defined.

Hmm, how about an expansion of (d):

Yes, this is very similar to the definition I have suggested. I think
this is a good compromise:

1) still allow implicit casts to bool from any type, as in
- value != 0
- obj_ref !is null
- pointer !is null
- array.ptr !is null
- !struct.opEquals(0) // does this work now?

This would mean that we would keep if(a && b) and also that the type of
any conditional could be defined as bool. But it would also mean that
you could write bool b = 5; I guess.

2) forbid casts from bool to anything else (even explicit; besides
"foo?1:0" is shorter and more obvious than "cast(int)foo")

I can live with explicit cast both being allowed and not. I don't see it
as an important detail. The important part is to disallow implicit casts
from bool to any type.

3) when an expression involves a bool operand, all other operands get
converted to bool

This is the logical conclusion from 1) and 2).

4) forbid all operators on bools, except ==, !=, &&, ||, &, |, and !. (&
and | don't short-circuit evaluation, but are otherwise equivalent to &&
and ||).

For consistency, ~ should be supported too. And ^ too of course.

/Oskar
```
Mar 03 2006
xs0 <xs0 xs0.com> writes:
```Oskar Linde wrote:
xs0 wrote:

Don Clugston wrote:

whereas Kyle said:

integer operations are illegal, and it cant be cast to anything.

So there are at least four types of bool being discussed. Probably more.
And at least two can be called "pure bool".
...
(d) Kyle

Right now, (a) and (c) are the only ones which are clearly defined.

Hmm, how about an expansion of (d):

Yes, this is very similar to the definition I have suggested. I think
this is a good compromise:

1) still allow implicit casts to bool from any type, as in
- value != 0
- obj_ref !is null
- pointer !is null
- array.ptr !is null
- !struct.opEquals(0) // does this work now?

This would mean that we would keep if(a && b) and also that the type of
any conditional could be defined as bool. But it would also mean that
you could write bool b = 5; I guess.

Yup, but I think it's good that with

bool b=expr;
if (b) {
}

the if statement's condition always evaluates exactly the same as with

if (expr) {
}

even though the "=5" case indeed looks somewhat odd. It should be
declared bad style to write that :)

2) forbid casts from bool to anything else (even explicit; besides
"foo?1:0" is shorter and more obvious than "cast(int)foo")

I can live with explicit cast both being allowed and not. I don't see it
as an important detail. The important part is to disallow implicit casts
from bool to any type.

Well, if you allow/provide a cast, it's most probably going to be to 0
and 1, which somewhat implies sort-of equivalence between 1 and true,
and that's probably not a good thing.. it would mean that it'd still be
possible to do arithmetics with booleans, which I believe should be avoided.

4) forbid all operators on bools, except ==, !=, &&, ||, &, |, and !.
(& and | don't short-circuit evaluation, but are otherwise equivalent
to && and ||).

For consistency, ~ should be supported too. And ^ too of course.

Well, we have ! and != already, I'm not sure what there's to gain from
having duplicates?

xs0
```
Mar 03 2006
Tom <Tom_member pathlink.com> writes:
```In article <du9ff8\$2ltg\$1 digitaldaemon.com>, Don Clugston says...
Tom wrote:
In article <du9cnl\$2h9j\$3 digitaldaemon.com>, Bruno Medeiros says...
Don Clugston wrote:
Tom wrote:
In article <du71jc\$1e9h\$1 digitaldaemon.com>, Bruno Medeiros says...
Walter Bright wrote:
"Tom" <Tom_member pathlink.com> wrote in message
news:du049t\$2uv2\$1 digitaldaemon.com...
Yes, PLEASE, WHY?? Just ONE argument against pure bools, only one
and I shut my
mouth forever!

One should be very careful about stepping away from C's implicit
promotion rules for a language that aims to be a successor to C. C
absolutely *buried* Pascal.

Uuh, I'm not sure what Tom meant by "pure bools", nor I'm sure what
you meant by "C's implicit promotion rules" (as C doesn't even have a
bool). But ok, nevermind, let's pause for a moment, and get our facts
straight.

What exactly is it in bools that you Walter, want and not want?
I already know that the ability to write 'while(1)' as the same as
'while(true)' is one of them, but, anything more?
Is the behaviour of having an "implicit promotion" something you want
too?
If so, promotion from where, from int to bool, or from bool to int?
Do you want or not want bool numeric operations to be an error (like
boolA / boolB*2) ?

You should read the latest posts about this stuff (the most with
subject "Re:
DMD 0.148 release"). It's all said there. By "pure bools" I mean the
*purist
kind* of boolean type. A boolean type that abstracts us from the
implementation.

Sorry, that's still not clear.
Bruno is right, terms like "pure bools" or "purist bools" are vague, you
can't expect everyone to know what you mean.

[snip]

Derek made a post some time ago with one such definition
(news://news.digitalmars.com:119/14shfnb64x5o2.17cec6fac7wnu.dlg 40tude.net).

And that is exactly what I meant when I said that you should read the latest
posts on the stuff :)

And if you read that post, you will find that Derek said:

** It can be explicitly cast to an integer such that false is 0, and
true is 1.

whereas Kyle said:

integer operations are illegal, and it cant be cast to anything.

So there are at least four types of bool being discussed. Probably more.
And at least two can be called "pure bool".
(a) the existing bool
(b) Bruno and I are in here somewhere, and are not necessarily the same.
(c) Derek
(d) Kyle

Right now, (a) and (c) are the only ones which are clearly defined.

You are right. So lets just call (c) "Derek's Bool".
And now that the definition has been made, I vote for "Derek's Bool" :D

Tom;
```
Mar 03 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Don Clugston wrote:
You should read the latest posts about this stuff (the most with
subject "Re:
DMD 0.148 release"). It's all said there. By "pure bools" I mean the
*purist
kind* of boolean type. A boolean type that abstracts us from the
implementation.

Sorry, that's still not clear.
Bruno is right, terms like "pure bools" or "purist bools" are vague, you
can't expect everyone to know what you mean.

For example: do you want "&" to be legal for bool types, or just "&&"?

Just &&.

(they mean very different things for integers). "&" normally means
"bitwise and", but a pure bool doesn't have any bits.
Is it legal to cast from a bool to some other type?

I'm not against casting but implicit conversions are bad.

> A boolean type that abstracts us from the implementation.

No abstraction is perfect. Does a bool have a defined bit
representation? (If you say 'no' to this, then I don't think a bool
could be used in an extern function, you'd always have to convert it to
int or something).

I think D ABI should define an internal representation, but it should be
abstracted from the user, so that the user doesn't have tok know
anything about it.

You make a good point about passing bool to extern functions, but one
could argue that even right now you are calling extern functions using
bools with a couple assumptions in mind. For example that the function
uses 0==false and true==everything but 0. But that doesn't have to be true.
```
Mar 03 2006
Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
```Ivan Senji wrote:
Don Clugston wrote:
Sorry, that's still not clear.
Bruno is right, terms like "pure bools" or "purist bools" are vague,
you can't expect everyone to know what you mean.

For example: do you want "&" to be legal for bool types, or just "&&"?

Just &&.

Why? Ever heard of boolean algebra? Why should &,|,^,~ not be defined
and allowed for bool? It would be problematic and inconsistent not
having non-short-circuit operators for booleans.

(they mean very different things for integers). "&" normally means
"bitwise and", but a pure bool doesn't have any bits.
Is it legal to cast from a bool to some other type?

I'm not against casting but implicit conversions are bad.

Do you mean that all implicit conversions are bad? Are the integer
promotion rules bad?

/Oskar
```
Mar 03 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Oskar Linde wrote:
Ivan Senji wrote:

Don Clugston wrote:

Sorry, that's still not clear.
Bruno is right, terms like "pure bools" or "purist bools" are vague,
you can't expect everyone to know what you mean.

For example: do you want "&" to be legal for bool types, or just "&&"?

Just &&.

Why? Ever heard of boolean algebra?

Ever heard of logic operators && and ||? That is what they are for.

Why should &,|,^,~ not be defined
and allowed for bool? It would be problematic and inconsistent not
having non-short-circuit operators for booleans.

I learned from xs0's reply that Java uses &,| for non-short-circuit
evaluation when arguments are of type bool. As D doesn't have a bool in
the Java meaning I don't think making & anything but bitwise operator
makes sense.

(they mean very different things for integers). "&" normally means
"bitwise and", but a pure bool doesn't have any bits.
Is it legal to cast from a bool to some other type?

I'm not against casting but implicit conversions are bad.

Do you mean that all implicit conversions are bad? Are the integer
promotion rules bad?

Ofcourse not. But with bools yes.

Do you think:
bool b = 5; would be a good thing?

int x = b/3; would be a good thing?
```
Mar 03 2006
Oskar Linde <olREM OVEnada.kth.se> writes:
```Ivan Senji wrote:

Oskar Linde wrote:
Ivan Senji wrote:

Don Clugston wrote:

Sorry, that's still not clear.
Bruno is right, terms like "pure bools" or "purist bools" are vague,
you can't expect everyone to know what you mean.

For example: do you want "&" to be legal for bool types, or just "&&"?

Just &&.

Why? Ever heard of boolean algebra?

Ever heard of logic operators && and ||? That is what they are for.

&& and || controls the program flow. They are not algebraic operators.
&,|,~,^ are real operators that also maps directly onto machine
instructions on most cpu architectures. Their meaning would be well defined
for bools. && and || requires branching and are therefore much less
efficient (even though this can be optimized away in many cases).

Also, not allowing ^ for bools would mean that code that reads a^b today
would have to be rewritten as:

(a && !b) || (!a && b).

Why should &,|,^,~ not be defined
and allowed for bool? It would be problematic and inconsistent not
having non-short-circuit operators for booleans.

I learned from xs0's reply that Java uses &,| for non-short-circuit
evaluation when arguments are of type bool. As D doesn't have a bool in
the Java meaning I don't think making & anything but bitwise operator
makes sense.

Huh? There have been regular discussions on the D newsgroups about bool
since atleast 2001. Almost all threads about this have people arguing for
the introduction of a logical (as opposed to the current numerical) bool
type similar (not necessarily identical) to the Java boolean. Isn't this
what we are discussing here too?

(they mean very different things for integers). "&" normally means
"bitwise and", but a pure bool doesn't have any bits.
Is it legal to cast from a bool to some other type?

I'm not against casting but implicit conversions are bad.

Do you mean that all implicit conversions are bad? Are the integer
promotion rules bad?

Ofcourse not. But with bools yes.

I read your statement as meaning that all implicit conversions are bad. I
was merely interested in why you thought so. :)

/Oskar
```
Mar 03 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Oskar Linde wrote:
&& and || controls the program flow.

If's and while's containing them control program flow (or I didn't get
something right?)

They are not algebraic operators.

They are logic operators. (Ok algebraic if we are talking about Boolean
algebra).

&,|,~,^ are real operators that also maps directly onto machine
instructions on most cpu architectures.

Sure they are, and I use them all the time on ints.

Their meaning would be well defined
for bools.

Not really:
bool a = //somehow 2
bool b = //somehow 4
a && b == true && true == true
a & b == 0x0010 & 0x0100 == 0x0000 == false,

I mean they would work but only if true == always 1 and false == always 0.

&& and || requires branching and are therefore much less
efficient (even though this can be optimized away in many cases).

Also, not allowing ^ for bools would mean that code that reads a^b today
would have to be rewritten as:

(a && !b) || (!a && b).

Oops, forgot about that one, so ^ can stay :)

Why should &,|,^,~ not be defined
and allowed for bool? It would be problematic and inconsistent not
having non-short-circuit operators for booleans.

I learned from xs0's reply that Java uses &,| for non-short-circuit
evaluation when arguments are of type bool. As D doesn't have a bool in
the Java meaning I don't think making & anything but bitwise operator
makes sense.

Huh? There have been regular discussions on the D newsgroups about bool
since atleast 2001.

Tell me about it, I think it is an neverending topic for D. Maybe even
if Walter got bools 'right' some people would be complaining.

Almost all threads about this have people arguing for
the introduction of a logical (as opposed to the current numerical) bool
type similar (not necessarily identical) to the Java boolean. Isn't this
what we are discussing here too?

I think so.
In the paragraf you replyed to I was just trying to say that having &,|
and ^ for bools only has meaning f they are strict logic bools and not
numeric.

(they mean very different things for integers). "&" normally means
"bitwise and", but a pure bool doesn't have any bits.
Is it legal to cast from a bool to some other type?

I'm not against casting but implicit conversions are bad.

Do you mean that all implicit conversions are bad? Are the integer
promotion rules bad?

Ofcourse not. But with bools yes.

I read your statement as meaning that all implicit conversions are bad. I
was merely interested in why you thought so. :)

Well, I think I would be crazy to think that ;)
```
Mar 03 2006
Oskar Linde <olREM OVEnada.kth.se> writes:
```Ivan Senji wrote:

Oskar Linde wrote:
&& and || controls the program flow.

If's and while's containing them control program flow (or I didn't get
something right?)

They control program flow by themselves too:

my_if() && (my_then(),1) || my_else();

Is equivalent to:

if (my_if())
my_then();
else
my_else();

&,|,~,^ are real operators that also maps directly onto machine
instructions on most cpu architectures.

Sure they are, and I use them all the time on ints.

Their meaning would be well defined
for bools.

Not really:
bool a = //somehow 2
bool b = //somehow 4
a && b == true && true == true
a & b == 0x0010 & 0x0100 == 0x0000 == false,

I mean they would work but only if true == always 1 and false == always 0.

We all seem to be talking about different kinds of bool :).

[snip]

In the paragraf you replyed to I was just trying to say that having &,|
and ^ for bools only has meaning f they are strict logic bools and not
numeric.

I see. I was talking about logical bools. Btw, the current bool (and C99
_Bool, C++ bool) is defined to be either 1 or 0. Without sidestepping the
type system there is no way to make a bool take any other value. This means
that both numeric operators and bitwise operator are well defined. A bool
can never somehow be 2 or somehow be 4. Assigning x to a bool makes an
implicit (x!=0). Another numeric boolean representation where the least
significant bit defines the truth state would also work with bit
operations.

The bool you seem to be talking about is one where any numeric value != 0
would represent true?

/Oskar
```
Mar 04 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Oskar Linde wrote:
Ivan Senji wrote:

Oskar Linde wrote:

&& and || controls the program flow.

If's and while's containing them control program flow (or I didn't get
something right?)

They control program flow by themselves too:

my_if() && (my_then(),1) || my_else();

Is equivalent to:

if (my_if())
my_then();
else
my_else();

Cool, I am never going to use if,then,else again ;)
This is so much cooler :)

&,|,~,^ are real operators that also maps directly onto machine
instructions on most cpu architectures.

Sure they are, and I use them all the time on ints.

Their meaning would be well defined
for bools.

Not really:
bool a = //somehow 2
bool b = //somehow 4
a && b == true && true == true
a & b == 0x0010 & 0x0100 == 0x0000 == false,

I mean they would work but only if true == always 1 and false == always 0.

We all seem to be talking about different kinds of bool :).

That is true.

[snip]

In the paragraf you replyed to I was just trying to say that having &,|
and ^ for bools only has meaning f they are strict logic bools and not
numeric.

I see. I was talking about logical bools. Btw, the current bool (and C99
_Bool, C++ bool) is defined to be either 1 or 0. Without sidestepping the
type system there is no way to make a bool take any other value. This means
that both numeric operators and bitwise operator are well defined. A bool
can never somehow be 2 or somehow be 4. Assigning x to a bool makes an
implicit (x!=0). Another numeric boolean representation where the least
significant bit defines the truth state would also work with bit
operations.

I did some teseting and it seems to be true. Then my only objection
would be if and while taking non boolean arguments, or put differently
implicit conversions from bool. But I'm going to stop complaining now
and learn to continue to live with how it is now...

The bool you seem to be talking about is one where any numeric value != 0
would represent true?

Not really, I'm talking about an i'dont-care-what-it-is bool. :)
```
Mar 04 2006
Miles <_______ _______.____> writes:
```(your KNode is breaking threads!)

Oskar Linde wrote:
Also, not allowing ^ for bools would mean that code that reads a^b today
would have to be rewritten as:

(a && !b) || (!a && b).

Err... what you want is just: a != b
```
Mar 04 2006
Oskar Linde <olREM OVEnada.kth.se> writes:
```Miles wrote:

(your KNode is breaking threads!)

I apologize. I didn't notice that KNode put a single group
followup-to-header instead of keeping cross-posting (I assume this is what
you are referring to). I will remove the follow-up from this post, but I
think KNodes behavior is correct. It is stupid to keep cross-posting this
discussion on the two probably most read D newsgroups.

Oskar Linde wrote:
Also, not allowing ^ for bools would mean that code that reads a^b today
would have to be rewritten as:

(a && !b) || (!a && b).

Err... what you want is just: a != b

That's right. I somehow overlooked that. :)

/Oskar
```
Mar 05 2006
Miles <_______ _______.____> writes:
```Oskar Linde wrote:
I apologize. I didn't notice that KNode put a single group
followup-to-header instead of keeping cross-posting (I assume this is what
you are referring to). I will remove the follow-up from this post, but I
think KNodes behavior is correct. It is stupid to keep cross-posting this
discussion on the two probably most read D newsgroups.

It is a bug, indeed. See https://bugs.kde.org/show_bug.cgi?id=68732 .

This "misfeature" causes much more confusion than solution, and it
forces something that is not natural. KNode sets a followup-to header to
groups that you are not subscribed. Most of time, it also sets stupid
followups (like now, this discussion is much more relevant to D thant to
D.announce, and your KNode set it to D.announce). To finish, if people
replying to your message don't notice, they end up posting to newsgroups
they are perhaps not even subscribed, and will never see their own
posts. Even if they notice, it is a pain to manually fix the destination.

This behavior of KNode is more annoying than anything, and it makes it
looks like cross-posts are something evil, while in fact they are useful
and there is a perfect reason for them.

Well... this is getting way off-topic...
```
Mar 05 2006
"Walter Bright" <newshound digitalmars.com> writes:
```"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:du002m\$2pnp\$1 digitaldaemon.com...
The code could have been while(5). Do you really think 5 is true?

The while expression must be convertible to a boolean, it needn't be a
boolean. I'm perfectly comfortable with the !=0 nature of the test, and not
just because I've been doing it for 25 years. It was comfortable right out
of the gate (and I came to C from Pascal, and never wrote another line of
Pascal after my first encounter with C).

The problem in all these bool wars so far is I never saw an argument that
would be against true booleans (while(BooleanExpression) and all that...).
The arguments like:
while(true) is much much bigger than while(1) or
while(a)    is much smaller and more understandable than while(a>0)
//hm while(a) is actually while(a!=0) but did I really mean a>0?)
and like that don't really count.

Adding true booleans makes no code break, only adds compiler errors that
make  a coder think more about what he is doing and require awfull changes
from if(b) to if(b!=0) and stop him from doing things like adding two
bools or adding an int to a bool.

Like I said, I never looked back with nostalgia upon Pascal after using C
<g>. I know many people think the wordier versions are more readable. I
don't. I'm also very reluctant to abandon things that may have contributed
to C being wildly popular and burying Pascal in an unmarked grave out in the
desert.

I still wonder why do you think that many modern and much used languages
implement real boolean types and are very proud of that? Does the
behaviour of D really fix C/C++ bool isues? Will those seeking a real bool
people not say <g> and write alias/typedef int boolean, or something else?

I think those languages have bools because they realize bool is *not* an
int but a mathematical concept.

Bool's particular behavior just doesn't have the leverage to make much of
any difference in real programs. On_scope is far more interesting, because
for a certain class of programming problems it can have a dramatic effect on
improving them.
```
Feb 28 2006
"Lionello Lunesu" <lio remove.lunesu.com> writes:
``` Bool's particular behavior just doesn't have the leverage to make much of
any difference in real programs. On_scope is far more interesting, because
for a certain class of programming problems it can have a dramatic effect
on improving them.

That's actually the best point so far. I agree.

L.
```
Feb 28 2006
Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
```Walter Bright wrote:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
The problem in all these bool wars so far is I never saw an argument that
would be against true booleans (while(BooleanExpression) and all that...).
The arguments like:
while(true) is much much bigger than while(1) or
while(a)    is much smaller and more understandable than while(a>0)
//hm while(a) is actually while(a!=0) but did I really mean a>0?)
and like that don't really count.

Adding true booleans makes no code break, only adds compiler errors that
make  a coder think more about what he is doing and require awfull changes
from if(b) to if(b!=0) and stop him from doing things like adding two
bools or adding an int to a bool.

Like I said, I never looked back with nostalgia upon Pascal after using C
<g>. I know many people think the wordier versions are more readable. I
don't. I'm also very reluctant to abandon things that may have contributed
to C being wildly popular and burying Pascal in an unmarked grave out in the
desert.

Thinking about that (the Pascal verbosity), I find that in most cases I
agree that wordier versions are less readable, however, that is only
*usually*, not in all situations. It really has to be considered on an
individual case, not on a general basis.
For instance, I abhor the BEGIN/END construct, so much that I
immediately distrust any language with it (yes Ruby, that means you..).
I also find stuff like VAR and THEN annoying, but in the case of '1' vs
'true', I prefer 'true'.
We can't go completely against the way of wordiness, because that would
be the road to obfuscation. Do not generalize, look at each case
appropriately. And harmony is the key.

--
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to
be... unnatural."
```
Feb 28 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Walter Bright wrote:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:dttebh\$2kqq\$1 digitaldaemon.com...

Ever seen this:

while(1)

I sure did, and it scares the hell out of me :)

Why? This is a practice I got into with C/C++, and I did it because 1 cannot
be redefined by the preprocessor into something goofy. I.e., I *knew* what
it was without having to go spelunking through header files.

One more thing. I heared from a Ruby user that in Ruby 0 means true.
To that user while(1) is pefectly obvious it is a block of code executed
exactly once. No problems in understanding that for a Ruby user.

But to me 1 isn't true, and isn't false. It is an implementation detail
that should be hidden from users.

As I said in another thread: programming language constructs should have
a meaning when translated to a human language.

What would: "if 75 then some people dont like type safety" mean? To me
and a lot more people it means nothing.
```
Feb 27 2006
Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
```Ivan Senji wrote:
One more thing. I heared from a Ruby user that in Ruby 0 means true.

To clarify, since that makes it sound a bit too much like "...and 1 means
false": in Ruby the only two things that are false are, of course, false itself,
and nil, which is similar to D's null. 0, like all other numbers, is true.
```
Feb 27 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Deewiant wrote:
Ivan Senji wrote:

One more thing. I heared from a Ruby user that in Ruby 0 means true.

To clarify, since that makes it sound a bit too much like "...and 1 means
false": in Ruby the only two things that are false are, of course, false
itself,
and nil, which is similar to D's null. 0, like all other numbers, is true.

Thanks for the clarification. It is really interesting how Ruby takes a
completly different approach. Not that I agree with it. Strange and
arbitrary decision IMO to make all numbers true. Why not make all
numbers false?
```
Feb 27 2006
Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
```Ivan Senji wrote:
Deewiant wrote:
Ivan Senji wrote:

One more thing. I heared from a Ruby user that in Ruby 0 means true.

To clarify, since that makes it sound a bit too much like "...and 1 means
false": in Ruby the only two things that are false are, of course,
false itself,
and nil, which is similar to D's null. 0, like all other numbers, is
true.

Thanks for the clarification. It is really interesting how Ruby takes a
completly different approach. Not that I agree with it. Strange and
arbitrary decision IMO to make all numbers true. Why not make all
numbers false?

Probably because of Ruby's TIMTOWTDI approach - There Is More Than One Way To Do
It. Thus, it tries to cater to programmers of all languages - including C, and
so if you liked to write "while (1)" before you can still write "while (1)". You
can also write "loop do", "for (;;)", "while (true)", and probably do the same
thing in at least a dozen other ways.

Point being that Ruby has no reason - and it might even be against its idioms -
to take so clearly a deviant approach to true and false as to declare numbers
false, when in most languages people nowadays use everything apart from 0 is
true.

Why, then, 0 is true, I cannot say; probably because all other numbers are true,
and 0 has no need to be an exception. It might be true in other languages
because they are strongly typed (or at least somewhat strongly - C isn't that
strongly typed, and even in D pointer arithmetic can do quite a bit to break the
type system, AFAIK), and a "false" value is very handy for a function that
returns an integer. In Ruby, you can just return false or nil, whichever is
appropriate, on error, even if the method in question normally returns an
integer.
```
Feb 27 2006
Charles Hixson <charleshixsn earthlink.net> writes:
```Ivan Senji wrote:

...
One more thing. I heared from a Ruby user that in Ruby 0 means true.
To that user while(1) is pefectly obvious it is a block of code executed
exactly once. No problems in understanding that for a Ruby user.
...

Yes.  IIRC in Ruby everything except Null and False is handled as if it were
true.  There's some justification that I can't remember...probably "That's
the way Perl does it", but that's just a guess.

OTOH, Ruby doesn't even TRY to be type safe.  I like Ruby a lot, but that's
not the way I think things should be handled.  And I'm all in favor of
Boolean being a type of size 1 that, if it implements + and *, implements
them as "or" and "and"...and NEVER automatically converts to or from any
arithmetic form.  That seems to me to be much more reasonable.  (Yes, C
didn't do it that way.  C didn't even HAVE a boolean type.  [Well, the
first C compilers I used didn't...bool was implemented via a macro
substitution for int.]  So I don't find that a very powerful argument for
what D should do.)

Still, no language is perfect, and as warts go, this is a small one.
```
Feb 27 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Charles Hixson wrote:
Ivan Senji wrote:

...
One more thing. I heared from a Ruby user that in Ruby 0 means true.
To that user while(1) is pefectly obvious it is a block of code executed
exactly once. No problems in understanding that for a Ruby user.
...

Yes.  IIRC in Ruby everything except Null and False is handled as if it were
true.  There's some justification that I can't remember...probably "That's
the way Perl does it", but that's just a guess.

OTOH, Ruby doesn't even TRY to be type safe.  I like Ruby a lot, but that's
not the way I think things should be handled.  And I'm all in favor of
Boolean being a type of size 1 that, if it implements + and *, implements
them as "or" and "and"...and NEVER automatically converts to or from any
arithmetic form.

Another Bool believer ;)

That seems to me to be much more reasonable.  (Yes, C
didn't do it that way.  C didn't even HAVE a boolean type.  [Well, the
first C compilers I used didn't...bool was implemented via a macro
substitution for int.]  So I don't find that a very powerful argument for
what D should do.)

I agree.

Still, no language is perfect, and as warts go, this is a small one.

No language is perfect, but I don't think it is souch a small problem in
a language claiming to be a modern language.
```
Feb 28 2006
Derek Parnell <derek psych.ward> writes:
```On Mon, 27 Feb 2006 01:29:07 +0200, Georg Wrede wrote:

Ok, I'll give an example of that right after you give an example of why
and where this is needed/good/(not extremly bad):

bool a, b, c;
a = true;
b = true;
c = true;

a = b+c; // true + true is what?

That's why we do want to have booleans. The whole point of having
booleans is to not do that by mistake.

But D currently allows this to happen. It's boolean implementation is
broken.

if(5) //if 5 what? what does that mean (except nothing)?

Ever seen this:

while(1)

written in source code?

Or this:

c = getCharacter(inf);
if (c) { /* whatever */ }

Oh, by the way, just checked how many times 'while(1)' appears in
src/phobos/std:

grep "while *( *1 *)" *.d |wc

answer: 16 times.

Aren't you reading my posts anymore ;-)

while(1)

is shorthand for

while (1 != 0)

and
c = getCharacter(inf);
if (c) { /* whatever */ }

is shorthand for

c = getCharacter(inf);
if (c != 0) { /* whatever */ }

--
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
27/02/2006 12:00:30 PM
```
Feb 26 2006
Derek Parnell <derek psych.ward> writes:
```On Mon, 27 Feb 2006 00:17:12 +0200, Georg Wrede wrote:

Derek Parnell wrote:
On Mon, 27 Feb 2006 06:05:13 +1100, Georg Wrede <georg nospam.org> wrote:

We've all had our fights with C, C++, and other related languages.
But  honestly, how many of us can confess to having problems with
logical  values?

Me.

And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future.

That's okay, you don't have to be embarrassed amongst friends. There are
still a lot of people that regard BASIC, and VB in particular, as 'not real
programming languages'.

---

I think we've gotten it backwards here, so let's turn the table:

Can you give some example code and use cases where we absolutely need
your kind of booleans?

Imagine that someone wrote a library function that reads a text file in and
returns the number of lines read in. You know that a file with less than 3
lines is invalid, so you write ...

int cnt = read_text(filename);
if (cnt < 3)
throw new Exception(...);

However, later on the library is updated and now returns a boolean: true if
successful, and false otherwise. Your programs will still compile but it
shouldn't. And it will always fail at run time even if the file read in
contained three or more lines.

However, if we had a true boolean semantics, the compiler would display an
error instead of you getting a run time error.

To point is that a language that implemented boolean semantics could help
eliminate a set of coding errors that D's 'bool' will not catch. In the
same way that 'real' and 'int' are used to catch such errors.

--
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
27/02/2006 9:58:09 AM
```
Feb 26 2006
Georg Wrede <georg nospam.org> writes:
```Derek Parnell wrote:
On Mon, 27 Feb 2006 00:17:12 +0200, Georg Wrede wrote:
Derek Parnell wrote:
Georg Wrede <georg nospam.org> wrote:

We've all had our fights with C, C++, and other related languages.
But  honestly, how many of us can confess to having problems with
logical  values?

Me.

And if someone here has such problems, I suggest switching to VB.

I am also a VB coder and I'm not a language bigot.

Oh. I'm sorry. I'll try not to mention VB in the future.

That's okay, you don't have to be embarrassed amongst friends. There are
still a lot of people that regard BASIC, and VB in particular, as 'not real
programming languages'.

Oh man, "still"!
Derek, you're killing me! :-)

BTW, did you too notice that the way this thread has been going the last
couple of hours and all posters here now, one'd think its Friday Night!
```
Feb 26 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Georg Wrede wrote:
Well, then we could skip the logical operators, right? No more && or ||.
Since all booleans would be strictly 0 or 1, they'd become obsolete.

What? Did you here this correctly? You are saying remove logical
operators (the operators working on booleans in theory)?

How would they become obsolete? They would get a meaning with true booleans.

I must say that i don't have a clue what is the result of 17 && 301?
But I do know that true && true == true.

And if booleans have to only be 0 or 1, then a whole lot of unnecessary
conversions would be happening all over the place. Forget D speed.

No they don't. They can be anything they wan't to be. But the compiler
should hide that from me and convince me I live in a world of Boolean
algebra.

Also, D is supposed to be a _systems_language_ for chrissake! Any kernel
writing would then have to forgo booleans totally.

No.

I'm all for features in D that enhance productivity, but deliberately
dumbing down the language is getting a bit too far.

Making it typesafe and consisten with mathematical definitions of bools
is dumbing? I somehow don't see why?

---

We've all had our fights with C, C++, and other related languages. But
honestly, how many of us can confess to having problems with logical
values?

I have problems with bools. I can't sleep at night if they are ints ;)
```
Feb 26 2006
Georg Wrede <georg nospam.org> writes:
```This is getting hilarious...

Ivan Senji wrote:
Georg Wrede wrote:

Well, then we could skip the logical operators, right? No more && or
||. Since all booleans would be strictly 0 or 1, they'd become obsolete.

What? Did you here this correctly? You are saying remove logical
operators (the operators working on booleans in theory)?

How would they become obsolete? They would get a meaning with true
booleans.

If Booleans are only 0 or 1, then & and | suffice. && and || become
useless, and we can delete them from the compiler sources.

Not to mention the lots of ink we could save!

I must say that i don't have a clue what is the result of 17 && 301?

I have no problem believing that's true.

And if booleans have to only be 0 or 1, then a whole lot of
unnecessary conversions would be happening all over the place. Forget
D speed.

No they don't. They can be anything they wan't to be. But the compiler
should hide that from me and convince me I live in a world of Boolean
algebra.

Since I've just promised not to recommend a certain language from
Redmond, maybe I could recommend some substance?

We've all had our fights with C, C++, and other related languages. But
honestly, how many of us can confess to having problems with logical
values?

I have problems with bools. I can't sleep at night if they are ints ;)

Oh. Maybe then a prescription substance?
```
Feb 26 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Georg Wrede wrote:
This is getting hilarious...

Really? I'm glad that this entertains you?

Ivan Senji wrote:

Georg Wrede wrote:

Well, then we could skip the logical operators, right? No more && or
||. Since all booleans would be strictly 0 or 1, they'd become obsolete.

What? Did you here this correctly? You are saying remove logical
operators (the operators working on booleans in theory)?

How would they become obsolete? They would get a meaning with true
booleans.

If Booleans are only 0 or 1, then & and | suffice. && and || become
useless, and we can delete them from the compiler sources.

That is one part I didn't understand. Why would booleans have to be 0 or
1? (or are you kidding, I'm too tired to be sure).

& is totally different from &&, & compares bits one by one, and && is
equivalent to * in Boolean algebra, two different concepts mustn't be
combined like that.

Not to mention the lots of ink we could save!

That's true.

I must say that i don't have a clue what is the result of 17 && 301?

I have no problem believing that's true.

And if booleans have to only be 0 or 1, then a whole lot of
unnecessary conversions would be happening all over the place. Forget
D speed.

No they don't. They can be anything they wan't to be. But the compiler
should hide that from me and convince me I live in a world of Boolean
algebra.

Since I've just promised not to recommend a certain language from
Redmond, maybe I could recommend some substance?

Sure, maybe C#? C# got bools right too.

We've all had our fights with C, C++, and other related languages.
But honestly, how many of us can confess to having problems with
logical values?

I have problems with bools. I can't sleep at night if they are ints ;)

Oh. Maybe then a prescription substance?

No thanks :)
```
Feb 26 2006
Georg Wrede <georg nospam.org> writes:
```Ivan Senji wrote:
Georg Wrede wrote:

That is one part I didn't understand. Why would booleans have to be 0 or
1? (or are you kidding, I'm too tired to be sure).

Since anything stored on a computer is representable with numbers, then
we could of course have true be 27 and false be 41.

But is there any profit in it, compared to 0 and 1?
```
Feb 26 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Georg Wrede wrote:
Ivan Senji wrote:

Georg Wrede wrote:

That is one part I didn't understand. Why would booleans have to be 0
or 1? (or are you kidding, I'm too tired to be sure).

Since anything stored on a computer is representable with numbers, then
we could of course have true be 27 and false be 41.

Starting to like this proposal but I would prefer true to be 42 (being
the answer to the universal question of everything)

But is there any profit in it, compared to 0 and 1?

Only the above.
```
Feb 26 2006
BCS <BCS_member pathlink.com> writes:
```In article <dttiq1\$2q5g\$1 digitaldaemon.com>, Ivan Senji says...
Georg Wrede wrote:
Ivan Senji wrote:

Since anything stored on a computer is representable with numbers, then
we could of course have true be 27 and false be 41.

Starting to like this proposal but I would prefer true to be 42 (being
the answer to the universal question of everything)

Ouch! And false must then be 54. (6*9) :P
```
Feb 26 2006
Kyle Furlong <kylefurlong gmail.com> writes:
```Georg Wrede wrote:

This is getting hilarious...

Ivan Senji wrote:
Georg Wrede wrote:

Well, then we could skip the logical operators, right? No more && or
||. Since all booleans would be strictly 0 or 1, they'd become obsolete.

What? Did you here this correctly? You are saying remove logical
operators (the operators working on booleans in theory)?

How would they become obsolete? They would get a meaning with true
booleans.

If Booleans are only 0 or 1, then & and | suffice. && and || become
useless, and we can delete them from the compiler sources.

Not to mention the lots of ink we could save!

I must say that i don't have a clue what is the result of 17 && 301?

I have no problem believing that's true.

And if booleans have to only be 0 or 1, then a whole lot of
unnecessary conversions would be happening all over the place. Forget
D speed.

No they don't. They can be anything they wan't to be. But the compiler
should hide that from me and convince me I live in a world of Boolean
algebra.

Since I've just promised not to recommend a certain language from
Redmond, maybe I could recommend some substance?

We've all had our fights with C, C++, and other related languages.
But honestly, how many of us can confess to having problems with
logical values?

I have problems with bools. I can't sleep at night if they are ints ;)

Oh. Maybe then a prescription substance?

Georg, reading your posts on this NG has given me great insight into the
breadth of your knowledge and the depth of your wisdom.
Your sarcasm is always poigniant and appropo. Your jibes at your fellow NG's
always in good taste. And your blind cheerleading
and bandwagoning the height of prudence and solid judgement. Keep up the good
work!
```
Feb 26 2006
Georg Wrede <georg nospam.org> writes:
```Kyle Furlong wrote:
Georg Wrede wrote:

This is getting hilarious...

Georg, reading your posts on this NG has given me great insight into the
breadth of your knowledge and the depth of your wisdom. Your sarcasm is
always poigniant and appropo. Your jibes at your fellow NG's always in
good taste. And your blind cheerleading and bandwagoning the height of
prudence and solid judgement. Keep up the good work!

Thanks!

Which reminds me, better go to bed before it gets too hilarious...

georg

PS, haven't had this much fun for a long time. I hope everyone else
enjoyed it too!
```
Feb 26 2006
Tom <Tom_member pathlink.com> writes:
```In article <44025193.2060501 nospam.org>, Georg Wrede says...
Kyle Furlong wrote:
Georg Wrede wrote:

This is getting hilarious...

Georg, reading your posts on this NG has given me great insight into the
breadth of your knowledge and the depth of your wisdom. Your sarcasm is
always poigniant and appropo. Your jibes at your fellow NG's always in
good taste. And your blind cheerleading and bandwagoning the height of
prudence and solid judgement. Keep up the good work!

Thanks!

Which reminds me, better go to bed before it gets too hilarious...

Me too, have to work and study tomorrow, shouldn't have "wasted" so much time
having fun with you guys.

georg

PS, haven't had this much fun for a long time. I hope everyone else
enjoyed it too!

I almost can say that I feel appreciation for all people involved (it's
unavoidable as you all seem to be nice guys). But remember, bool doesn't worth a
bloodshed :P

Tom;
```
Feb 26 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Georg Wrede wrote:
Kyle Furlong wrote:

Georg Wrede wrote:

This is getting hilarious...

Georg, reading your posts on this NG has given me great insight into
the breadth of your knowledge and the depth of your wisdom. Your
sarcasm is always poigniant and appropo. Your jibes at your fellow
NG's always in good taste. And your blind cheerleading and
bandwagoning the height of prudence and solid judgement. Keep up the
good work!

Thanks!

Which reminds me, better go to bed before it gets too hilarious...

georg

PS, haven't had this much fun for a long time. I hope everyone else
enjoyed it too!

Me too. NG chating is a funny thing.
```
Feb 26 2006
"Derek Parnell" <derek psych.ward> writes:
```On Mon, 27 Feb 2006 00:02:08 +1100, Georg Wrede <georg nospam.org> wrote:

Derek Parnell wrote:
Walter is still living in the C/C++ past with this concept, which is
strange seeing he has implemented so many progressive concepts in D.
Boolean as an integer is just retro.

So am I.

Apparently so.

Booleans have to be int.

Why? And do you mean they have to be implemented using 'int' or are you
saying that they are intrinsically integers?

A boolean may have any "numeric" value, but if   implicitly cast to a
numeric type, it should return 1 or 0.

Why?

D IS A PRACTICAL PROGRAMMING LANGUAGE.

Which means what, exactly? For example, does the term 'practical' also
embrace the concept of 'cost-effective to maintain'?

Forcing booleans to be 1/0 all the way is just academic, purist,
impractical bigotry. About as smart as having the bit type.

No one is saying that booleans must be forced to be 1/0? Why did you think
that this was what I was saying?

(Besides, if booleans, as some say here, are _only_ abstract concepts,
then we might as well decide to have 0 mean true and 1 mean false.

Exactly! The implementation is not the concept. Of course, this would not
be a very efficient implementation but it is a possiblity.

Heh, there's only one truth but millions of lies! But we live in a world
with other people. And computers.)

Did you just say that there is one 'zero' but millions of 'ones'?

Now, specifying 0 to mean false and everything else to mean not-false,
we go along with the hardware, the computer industry, half a century of
programming PRACTICE, and make life less difficult for anybody with a
professional programming background before moving to D.

And that's why it is a more efficient implementation. I agree that this is
how booleans will probably be implemented. But there are other sematics
that go with numbers that do not belong in the domain of booleans.

--
Derek Parnell
Melbourne, Australia
```
Feb 26 2006
James Dunne <james.jdunne gmail.com> writes:
```Derek Parnell wrote:
On Mon, 27 Feb 2006 00:02:08 +1100, Georg Wrede <georg nospam.org> wrote:

Derek Parnell wrote:

Walter is still living in the C/C++ past with this concept, which
is   strange seeing he has implemented so many progressive concepts
in D.   Boolean as an integer is just retro.

So am I.

Apparently so.

Booleans have to be int.

Why? And do you mean they have to be implemented using 'int' or are you
saying that they are intrinsically integers?

A boolean may have any "numeric" value, but if   implicitly cast to a
numeric type, it should return 1 or 0.

Why?

D IS A PRACTICAL PROGRAMMING LANGUAGE.

Which means what, exactly? For example, does the term 'practical' also
embrace the concept of 'cost-effective to maintain'?

Forcing booleans to be 1/0 all the way is just academic, purist,
impractical bigotry. About as smart as having the bit type.

No one is saying that booleans must be forced to be 1/0? Why did you
think  that this was what I was saying?

(Besides, if booleans, as some say here, are _only_ abstract
concepts,  then we might as well decide to have 0 mean true and 1 mean
false.

Exactly! The implementation is not the concept. Of course, this would
not  be a very efficient implementation but it is a possiblity.

Heh, there's only one truth but millions of lies! But we live in a
world  with other people. And computers.)

Did you just say that there is one 'zero' but millions of 'ones'?

I actually laughed out loud at that.  Good catch man.  This is why I
love this NG. :)

Now, specifying 0 to mean false and everything else to mean
not-false,  we go along with the hardware, the computer industry, half
a century of  programming PRACTICE, and make life less difficult for
anybody with a  professional programming background before moving to D.

And that's why it is a more efficient implementation. I agree that this
is  how booleans will probably be implemented. But there are other
sematics  that go with numbers that do not belong in the domain of
booleans.

--
Regards,
James Dunne
```
Feb 26 2006
Georg Wrede <georg nospam.org> writes:
```James Dunne wrote:
Derek Parnell wrote:

On Mon, 27 Feb 2006 00:02:08 +1100, Georg Wrede <georg nospam.org> wrote:

Derek Parnell wrote:

Walter is still living in the C/C++ past with this concept, which
is   strange seeing he has implemented so many progressive concepts
in D.   Boolean as an integer is just retro.

So am I.

Apparently so.

Booleans have to be int.

Why? And do you mean they have to be implemented using 'int' or are
you  saying that they are intrinsically integers?

A boolean may have any "numeric" value, but if   implicitly cast to
a  numeric type, it should return 1 or 0.

Why?

D IS A PRACTICAL PROGRAMMING LANGUAGE.

Which means what, exactly? For example, does the term 'practical'
also  embrace the concept of 'cost-effective to maintain'?

Forcing booleans to be 1/0 all the way is just academic, purist,
impractical bigotry. About as smart as having the bit type.

No one is saying that booleans must be forced to be 1/0? Why did you
think  that this was what I was saying?

(Besides, if booleans, as some say here, are _only_ abstract
concepts,  then we might as well decide to have 0 mean true and 1
mean false.

Exactly! The implementation is not the concept. Of course, this would
not  be a very efficient implementation but it is a possiblity.

Heh, there's only one truth but millions of lies! But we live in a
world  with other people. And computers.)

Did you just say that there is one 'zero' but millions of 'ones'?

I actually laughed out loud at that.  Good catch man.  This is why I
love this NG. :)

So did I. At myself.

Of course, I meant to write "decide to have 0 mean true and anything
else mean false -- only one truth but millions of lies".

Now, specifying 0 to mean false and everything else to mean
not-false,  we go along with the hardware, the computer industry,
half a century of  programming PRACTICE, and make life less difficult
for anybody with a  professional programming background before moving
to D.

And that's why it is a more efficient implementation. I agree that
this is  how booleans will probably be implemented. But there are
other sematics  that go with numbers that do not belong in the domain
of booleans.

```
Feb 26 2006
Wang Zhen <nehzgnaw gmail.com> writes:
```Derek Parnell wrote:
On Sun, 26 Feb 2006 17:29:03 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:

Derek Parnell wrote:

On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright
<newshound digitalmars.com> wrote:

Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

Well you almost got bool right <G> Everything except that it does
implicit  conversion to int. That is just a cheap cop out for lazy
coding, IMNSHO.

Pardon my ignorance,

That's okay.

but why does D need a primitive type for booleans in the first place?
What's wrong with "alias ubyte bool;" or "alias int bool;"?

The short answer is that booleans are not numbers. They represent truth
and falsehood.

Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

*We* are not C programmers ;-) *We* have grown up from that baby-talk ;-)

Zero is frequently used to implement the concept of falsehood and
likewise  non-zero for truth, however the semantics of integers is not
the same as  the semantics of booleans. But because many C programers
are just *so*  used to thinking this way they have become to believe
that zero *is*  falsehood rather than just a number chosen to implement
the concept.

32-bit int is frequently used to implement the concept of integers, but
they are semantically different. So what? Be a language purist and
refuse to call int an integer until programmers can store arbitrary
integers without having to worry about the implementation details?

It is quite possible for a language to implement falsehood/truth is
ways  other than using integers but even if they do, the compiler can
still  ensure that the sematics are adhered to rather than continue
using integer  sematics.

The only thing I can see wrong with D's new boolean is that it still
pretends its a number. Why is this wrong? Because it can lead to coding
mistakes and abuse. Thus making maintenance more costly than it needed
to  be.

Pretending that bool is not a number can possibly lead to more confusion
and misuse. Besides, many other features can also be abused in a
practical language like D. Abandon them all just in case some
unconscious programmer might make a mistake?

Walter is still living in the C/C++ past with this concept, which is
strange seeing he has implemented so many progressive concepts in D.
Boolean as an integer is just retro.

I'm still not convinced why oldschool integer bools are inferior to
newschool bools which may be abused by pointer tricks anyway.
```
Feb 26 2006
Kyle Furlong <kylefurlong gmail.com> writes:
```Wang Zhen wrote:
Derek Parnell wrote:
On Sun, 26 Feb 2006 17:29:03 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:

Derek Parnell wrote:

On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright
<newshound digitalmars.com> wrote:

Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

Well you almost got bool right <G> Everything except that it does
implicit  conversion to int. That is just a cheap cop out for lazy
coding, IMNSHO.

Pardon my ignorance,

That's okay.

but why does D need a primitive type for booleans in the first
place?  What's wrong with "alias ubyte bool;" or "alias int bool;"?

The short answer is that booleans are not numbers. They represent
truth  and falsehood.

Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

*We* are not C programmers ;-) *We* have grown up from that baby-talk ;-)

Zero is frequently used to implement the concept of falsehood and
likewise  non-zero for truth, however the semantics of integers is not
the same as  the semantics of booleans. But because many C programers
are just *so*  used to thinking this way they have become to believe
that zero *is*  falsehood rather than just a number chosen to
implement the concept.

32-bit int is frequently used to implement the concept of integers, but
they are semantically different. So what? Be a language purist and
refuse to call int an integer until programmers can store arbitrary
integers without having to worry about the implementation details?

It is quite possible for a language to implement falsehood/truth is
ways  other than using integers but even if they do, the compiler can
still  ensure that the sematics are adhered to rather than continue
using integer  sematics.

The only thing I can see wrong with D's new boolean is that it still
pretends its a number. Why is this wrong? Because it can lead to
coding  mistakes and abuse. Thus making maintenance more costly than
it needed to  be.

Pretending that bool is not a number can possibly lead to more confusion
and misuse. Besides, many other features can also be abused in a
practical language like D. Abandon them all just in case some
unconscious programmer might make a mistake?

Walter is still living in the C/C++ past with this concept, which is
strange seeing he has implemented so many progressive concepts in D.
Boolean as an integer is just retro.

I'm still not convinced why oldschool integer bools are inferior to
newschool bools which may be abused by pointer tricks anyway.

The point has to do with the type system. Yes, you can always hack any type by
using pointer tricks. So what is the point of
having a type system in the first place? Having all booleans as integers is
just wrong, they have different constraints, are
different kinds of entities, even if they are backed by the same kind of
storage.
```
Feb 26 2006
"Derek Parnell" <derek psych.ward> writes:
```On Mon, 27 Feb 2006 02:43:56 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:

Derek Parnell wrote:
On Sun, 26 Feb 2006 17:29:03 +1100, Wang Zhen <nehzgnaw gmail.com>
wrote:

Derek Parnell wrote:

On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright
<newshound digitalmars.com> wrote:

Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

Well you almost got bool right <G> Everything except that it does
implicit  conversion to int. That is just a cheap cop out for lazy
coding, IMNSHO.

Pardon my ignorance,

That's okay.

but why does D need a primitive type for booleans in the first place?
What's wrong with "alias ubyte bool;" or "alias int bool;"?

The short answer is that booleans are not numbers. They represent
truth  and falsehood.

Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

*We* are not C programmers ;-) *We* have grown up from that baby-talk
;-)
Zero is frequently used to implement the concept of falsehood and
likewise  non-zero for truth, however the semantics of integers is not
the same as  the semantics of booleans. But because many C programers
are just *so*  used to thinking this way they have become to believe
that zero *is*  falsehood rather than just a number chosen to implement
the concept.

32-bit int is frequently used to implement the concept of integers, but
they are semantically different.

I understood that a 32-bit int was used to implement a subset of integers,
not the whole range.

So what? Be a language purist and refuse to call int an integer until
programmers can store arbitrary integers without having to worry about
the implementation details?

An 'int' *is* an integer. But an integer is not necessarily an 'int'. I
don't find this a difficult concept.

It is quite possible for a language to implement falsehood/truth is
ways  other than using integers but even if they do, the compiler can
still  ensure that the sematics are adhered to rather than continue
using integer  sematics.
The only thing I can see wrong with D's new boolean is that it still
pretends its a number. Why is this wrong? Because it can lead to
coding  mistakes and abuse. Thus making maintenance more costly than it
needed to  be.

Pretending that bool is not a number can possibly lead to more confusion
and misuse. Besides, many other features can also be abused in a
practical language like D. Abandon them all just in case some
unconscious programmer might make a mistake?

Who is pretending? I'm not. A boolean is not a number. If it was, you
should be able to arithmetic with it, but 'what is truth raised to the
power 4?' is nonsense.

Walter is still living in the C/C++ past with this concept, which is
strange seeing he has implemented so many progressive concepts in D.
Boolean as an integer is just retro.

I'm still not convinced why oldschool integer bools are inferior to
newschool bools which may be abused by pointer tricks anyway.

Huh?

I'm not getting this across very well am I :)

D can use integers (32-bit ints) to implement booleans if this is
efficient. I have no problem with that. However, the compiler should not
allow arithmetic to be done on them, or implicit conversion of 'int' to
'bool' The compiler can detect this stuff and it is totally independant
how how they are implemented.

bool x;
x = 8;
if (x == 4)
{
writefln("This code says that 8 and 4 are the same");
}

bool x;
x = cast(bool)8;
if (x == cast(bool)4)
{
writefln("This code says that 8, when cast to a bool, "
"is the same as 4, when that is also cast to bool");
}

bool x;
x = true;
if (x == true)
{
writefln("This code says 'true' and 'true' are the same.");
}

--
Derek Parnell
Melbourne, Australia
```
Feb 26 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Derek Parnell wrote:
On Mon, 27 Feb 2006 02:43:56 +1100, Wang Zhen <nehzgnaw gmail.com> wrote:

Derek Parnell wrote:

32-bit int is frequently used to implement the concept of integers,
but  they are semantically different.

I understood that a 32-bit int was used to implement a subset of
integers,  not the whole range.

And that is exactly the way I understand it, actually it *is* that way.

So what? Be a language purist and refuse to call int an integer until
programmers can store arbitrary integers without having to worry
about  the implementation details?

An 'int' *is* an integer. But an integer is not necessarily an 'int'. I
don't find this a difficult concept.

Very simple concept indeed.

It is quite possible for a language to implement falsehood/truth is
ways  other than using integers but even if they do, the compiler
can  still  ensure that the sematics are adhered to rather than
continue  using integer  sematics.
The only thing I can see wrong with D's new boolean is that it
still   pretends its a number. Why is this wrong? Because it can lead
to  coding  mistakes and abuse. Thus making maintenance more costly
than it  needed to  be.

Pretending that bool is not a number can possibly lead to more
confusion  and misuse. Besides, many other features can also be abused
in a  practical language like D. Abandon them all just in case some
unconscious programmer might make a mistake?

Who is pretending? I'm not. A boolean is not a number. If it was, you
should be able to arithmetic with it, but 'what is truth raised to the
power 4?' is nonsense.

Well you might say that it is true*true*true*true == true && true &&
true && true == true :)

But than I would expect operators + and * to behave like || and &&.
:)
```
Feb 26 2006
Charles <noone nowhere.com> writes:
``` Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

Wang Zhen wrote:
Derek Parnell wrote:

On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright
<newshound digitalmars.com> wrote:

Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

Well you almost got bool right <G> Everything except that it does
implicit  conversion to int. That is just a cheap cop out for lazy
coding, IMNSHO.

Pardon my ignorance, but why does D need a primitive type for booleans
in the first place? What's wrong with "alias ubyte bool;" or "alias int
bool;"? Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

//--------------------
import std.stdio;

void main()
{
bool a;
bool b;
bool c;
bool d;
int e;

a = true;
b = true;
c = true;
d = a + b + c;
e = a + b + c; // In a decent implentation, this should have failed
to  compile
writefln("%s %s %s %s %s", a,b,c,d,e);
writefln("%d %d %d %d %d", a,b,c,d,e); // And this might have been
a  runtime error?

}
//-------------------

```
Feb 26 2006
Thomas Kuehne <thomas-dloop kuehne.cn> writes:
```-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Charles schrieb am 2006-02-26:
Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... }

instead of

if(b!=0) { ... }

can be found in quite a lot of C code ...

-----BEGIN PGP SIGNATURE-----

iD8DBQFEAfkq3w+/yD4P9tIRAjjeAKC1VyqNp5rrmzTVXSuwQXPlE/kFRwCfX+Uk
Dea9+c9tXcAGCxgklIpfUp0=
=rQqB
-----END PGP SIGNATURE-----
```
Feb 26 2006
"Regan Heath" <regan netwin.co.nz> writes:
```On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne
<thomas-dloop kuehne.cn> wrote:
Charles schrieb am 2006-02-26:
Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... }

instead of

if(b!=0) { ... }

can be found in quite a lot of C code ...

So?

Assuming:

- 'b' is a bool
- a bool can only have 2 values, 'true' and 'false'
- when you convert/promote a bool to an int you get: 'true'->'1',
'false'->'0'
- when you convert/promote an int to bool you get: '0'->false,
'!0'->'true'

Then:

if(b==1) { ... }

results in 'b' being converted to int, giving it the value 1, and the
comparrison working correctly.

Right?

Regan
```
Feb 26 2006
"Derek Parnell" <derek psych.ward> writes:
```On Mon, 27 Feb 2006 07:56:10 +1100, Regan Heath <regan netwin.co.nz> wrote:

On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne
<thomas-dloop kuehne.cn> wrote:
Charles schrieb am 2006-02-26:
Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... }

instead of

if(b!=0) { ... }

can be found in quite a lot of C code ...

So?

Assuming:

- 'b' is a bool
- a bool can only have 2 values, 'true' and 'false'
- when you convert/promote a bool to an int you get: 'true'->'1',
'false'->'0'
- when you convert/promote an int to bool you get: '0'->false,
'!0'->'true'

Then:

if(b==1) { ... }

results in 'b' being converted to int, giving it the value 1, and the
comparrison working correctly.

Right?

If it implemented that way, yes. However the problem with

if(b == 1)

is that the reader (future maintainer) might be mislead into thinking that
'b' is an integer and may try to use it as such by mistake. It is better
to inform the reader about the true nature of 'b' by writing

if (b == true)

in or to remove such ambiguity.

--
Derek Parnell
Melbourne, Australia
```
Feb 26 2006
"Regan Heath" <regan netwin.co.nz> writes:
```On Mon, 27 Feb 2006 08:48:11 +1100, Derek Parnell <derek psych.ward> wrote:
On Mon, 27 Feb 2006 07:56:10 +1100, Regan Heath <regan netwin.co.nz>
wrote:

On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne
<thomas-dloop kuehne.cn> wrote:
Charles schrieb am 2006-02-26:
Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... }

instead of

if(b!=0) { ... }

can be found in quite a lot of C code ...

So?

Assuming:

- 'b' is a bool
- a bool can only have 2 values, 'true' and 'false'
- when you convert/promote a bool to an int you get: 'true'->'1',
'false'->'0'
- when you convert/promote an int to bool you get: '0'->false,
'!0'->'true'

Then:

if(b==1) { ... }

results in 'b' being converted to int, giving it the value 1, and the
comparrison working correctly.

Right?

If it implemented that way, yes. However the problem with

if(b == 1)

is that the reader (future maintainer) might be mislead into thinking
that 'b' is an integer and may try to use it as such by mistake. It is
better to inform the reader about the true nature of 'b' by writing

if (b == true)

in or to remove such ambiguity.

Sure, but the example was old C code, presumably copied into a D source
file and used. Or perhaps a C programmer not used to having bool using '1'
for true. I was just pointing out that it was likely to work, not that it
was as clear as it could be.

Regan
```
Feb 26 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Regan Heath wrote:
On Mon, 27 Feb 2006 08:48:11 +1100, Derek Parnell <derek psych.ward> wrote:

On Mon, 27 Feb 2006 07:56:10 +1100, Regan Heath <regan netwin.co.nz>
wrote:

On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne
<thomas-dloop kuehne.cn> wrote:

Charles schrieb am 2006-02-26:

Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... }

instead of

if(b!=0) { ... }

can be found in quite a lot of C code ...

So?

Assuming:

- 'b' is a bool
- a bool can only have 2 values, 'true' and 'false'
- when you convert/promote a bool to an int you get: 'true'->'1',
'false'->'0'
- when you convert/promote an int to bool you get: '0'->false,
'!0'->'true'

Then:

if(b==1) { ... }

results in 'b' being converted to int, giving it the value 1, and
the  comparrison working correctly.

Right?

If it implemented that way, yes. However the problem with

if(b == 1)

is that the reader (future maintainer) might be mislead into thinking
that 'b' is an integer and may try to use it as such by mistake. It
is  better to inform the reader about the true nature of 'b' by writing

if (b == true)

in or to remove such ambiguity.

Sure, but the example was old C code, presumably copied into a D source
file and used. Or perhaps a C programmer not used to having bool using
'1'  for true. I was just pointing out that it was likely to work, not
that it  was as clear as it could be.

I usually want my code not only to likely work. That is just not enough.
What if someone writes D compiler for a strange CPU on which parity
instructions are faster than comparing to 0 or 1, then we could have
"true" == more zeros, "false" == more ones.

Or there could be any other imaginable implementation of bools and each
and every one will break on code like if(b==1), if(b==0), while(b), if(3)...
```
Feb 26 2006
"Regan Heath" <regan netwin.co.nz> writes:
```On Mon, 27 Feb 2006 00:32:25 +0100, Ivan Senji
<ivan.senji_REMOVE_ _THIS__gmail.com> wrote:
Regan Heath wrote:
On Mon, 27 Feb 2006 08:48:11 +1100, Derek Parnell <derek psych.ward>
wrote:

On Mon, 27 Feb 2006 07:56:10 +1100, Regan Heath <regan netwin.co.nz>
wrote:

On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne
<thomas-dloop kuehne.cn> wrote:

Charles schrieb am 2006-02-26:

Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... }

instead of

if(b!=0) { ... }

can be found in quite a lot of C code ...

So?

Assuming:

- 'b' is a bool
- a bool can only have 2 values, 'true' and 'false'
- when you convert/promote a bool to an int you get: 'true'->'1',
'false'->'0'
- when you convert/promote an int to bool you get: '0'->false,
'!0'->'true'

Then:

if(b==1) { ... }

results in 'b' being converted to int, giving it the value 1, and
the  comparrison working correctly.

Right?

If it implemented that way, yes. However the problem with

if(b == 1)

is that the reader (future maintainer) might be mislead into thinking
that 'b' is an integer and may try to use it as such by mistake. It
is  better to inform the reader about the true nature of 'b' by writing

if (b == true)

in or to remove such ambiguity.

Sure, but the example was old C code, presumably copied into a D
source  file and used. Or perhaps a C programmer not used to having
bool using '1'  for true. I was just pointing out that it was likely to
work, not that it  was as clear as it could be.

I usually want my code not only to likely work. That is just not enough.

By "likely" I actually meant it "will definately" work provided it is
implemented in the way in which it is "likely" to be implemented. In other
words, if it's done how I think it will be done, it "will" work fine.

What if someone writes D compiler for a strange CPU on which parity
instructions are faster than comparing to 0 or 1, then we could have
"true" == more zeros, "false" == more ones.

Or there could be any other imaginable implementation of bools and each
and every one will break on code like if(b==1), if(b==0), while(b),
if(3)...

All that is "possible" if not "likely".

Regan
```
Feb 26 2006
Thomas Kuehne <thomas-dloop kuehne.cn> writes:
```-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Regan Heath schrieb am 2006-02-26:
On Sun, 26 Feb 2006 18:46:10 +0000 (UTC), Thomas Kuehne
<thomas-dloop kuehne.cn> wrote:
Charles schrieb am 2006-02-26:
Can't we simply treat zero as false and non-zero as true as we C
programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

if(b==1) { ... }

instead of

if(b!=0) { ... }

can be found in quite a lot of C code ...

So?

Assuming:

- 'b' is a bool
- a bool can only have 2 values, 'true' and 'false'
- when you convert/promote a bool to an int you get: 'true'->'1',
'false'->'0'
- when you convert/promote an int to bool you get: '0'->false,
'!0'->'true'

Then:

if(b==1) { ... }

results in 'b' being converted to int, giving it the value 1, and the
comparrison working correctly.

Right?

# import std.stdio;
#
# int main(){
#	int i = 3;
#	bool a = true;
#	bool b = *(cast(bool*)cast(void*) &i);
#
#	writefln("a: %s", a);
#	writefln("b: %s", b);
#	writefln("int: %s", cast(int)b); // line 9
#	writefln("a+b: %s", a+b); // line 10
#
#	return 0;
# }

I know, nobody writes code like that ...

surprise:
true -> 3 // line 9
true + true -> 4 // line 10

- when you convert/promote a bool to an int you get: 'true'->'1',
'false'->'0'

The problem is: that assumtion isn't easily enforcable if bool is
treated as an integer type.

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFEAjK+3w+/yD4P9tIRAoFmAJ4lNdg1i5/SbYNKvN+21jiF+L4wiACgusY4
JZugXrusKOTK629hFhxmR9A=
=oxIq
-----END PGP SIGNATURE-----
```
Feb 26 2006
"Regan Heath" <regan netwin.co.nz> writes:
```On Sun, 26 Feb 2006 22:03:20 +0000 (UTC), Thomas Kuehne
<thomas-dloop kuehne.cn> wrote:
- when you convert/promote a bool to an int you get: 'true'->'1',
'false'->'0'

The problem is: that assumtion isn't easily enforcable if bool is
treated as an integer type.

I'm no assembler expert but isn't there a single instruction for comparing
to 0? Can't you therefore convert to bool with that, or it's inverse?

Regan
```
Feb 26 2006
"Walter Bright" <newshound digitalmars.com> writes:
```"Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message
news:0fo9d3-mb8.ln1 birke.kuehne.cn...
# import std.stdio;
#
# int main(){
# int i = 3;
# bool a = true;

The next line goes around the type system completely, invalidates any
invariants on the contents, and so any "surprising" results should be
unsurprising:

# bool b = *(cast(bool*)cast(void*) &i);

#
# writefln("a: %s", a);
# writefln("b: %s", b);
# writefln("int: %s", cast(int)b); // line 9
# writefln("a+b: %s", a+b); // line 10
#
# return 0;
# }

I know, nobody writes code like that ...

surprise:
true -> 3 // line 9
true + true -> 4 // line 10

```
Feb 27 2006
Thomas Kuehne <thomas-dloop kuehne.cn> writes:
```-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright schrieb am 2006-02-27:
"Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message
news:0fo9d3-mb8.ln1 birke.kuehne.cn...
# import std.stdio;
#
# int main(){
# int i = 3;
# bool a = true;

The next line goes around the type system completely, invalidates any
invariants on the contents, and so any "surprising" results should be
unsurprising:

# bool b = *(cast(bool*)cast(void*) &i);

I was sure there was another way to subvert without casting though
can't find it right now.

related suggestion:

a) if( a == b ) { ... }
b) if( a != b ) { ... }

If, after constant folding, the lines above results in

a) if( a == true ) { ... }
b) if( a != true ) { ... }

then the the code

a) if( a != false ) { ... }
b) if( a == false ) { ... }

is generated.

consequences:
1) no changes in the D documentation are required

2) no runtime overhead

3) the code is a bit more robust against casting and bools returned
from external sources (e.g. C code)

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFEBOB93w+/yD4P9tIRAlJpAJ9IdclZxNNPVFIEl0N/jLrwlC1EAACeNnGi
4fXZOJBKlc/5ES50zb21khs=
=HMVz
-----END PGP SIGNATURE-----
```
Feb 28 2006
"Walter Bright" <newshound digitalmars.com> writes:
```"Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message
news:2t3fd3-hm9.ln1 birke.kuehne.cn...
3) the code is a bit more robust against casting and bools returned
from external sources (e.g. C code)

That's true, but I disagree with the intent. When interfacing with C, or
doing casting, it's up to you to get the right results into the variable to
satisfy the constraints of the type. Having the compiler essentially hide
bugs of this sort doesn't make it robust, it just defers the problem to
cropping up somewhere else.
```
Feb 28 2006
"Derek Parnell" <derek psych.ward> writes:
```On Mon, 27 Feb 2006 04:36:08 +1100, Charles <noone nowhere.com> wrote:

> Can't we simply treat zero as false and non-zero as true as we C
> programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

Should a coder be allowed by the compiler to perform arithemtic operations
of booleans?

--
Derek Parnell
Melbourne, Australia
```
Feb 26 2006
Georg Wrede <georg nospam.org> writes:
```Derek Parnell wrote:
On Mon, 27 Feb 2006 04:36:08 +1100, Charles <noone nowhere.com> wrote:

> Can't we simply treat zero as false and non-zero as true as we C
> programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

Should a coder be allowed by the compiler to perform arithemtic
operations  of booleans?

No.

And that's why nobody (to my knowledge) is opposing _having_ booleans.
```
Feb 26 2006
Derek Parnell <derek psych.ward> writes:
```On Mon, 27 Feb 2006 00:34:07 +0200, Georg Wrede wrote:

Derek Parnell wrote:
On Mon, 27 Feb 2006 04:36:08 +1100, Charles <noone nowhere.com> wrote:

> Can't we simply treat zero as false and non-zero as true as we C
> programmers always do?

I agree, I still don't get what the 'true bool' fuss is about .

Should a coder be allowed by the compiler to perform arithemtic
operations  of booleans?

No.

And that's why nobody (to my knowledge) is opposing _having_ booleans.

Then why the objection to having them as booleans rather than numbers?

One purpose for having a compiler is to help coders reduce the number of
mistakes that they could make. And one of the reasons we have a type system
in compilers is to catch a set of potential mistakes that coders make. If
we pretend that booleans are number types, we deny an opportunity to catch
potential coding mistakes.

--
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
27/02/2006 9:53:51 AM
```
Feb 26 2006
John Reimer <terminal.node gmail.com> writes:
```Walter Bright wrote:
Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

http://www.digitalmars.com/d/changelog.html

:P

New releases with bug fixes are always welcome, and I'm excited at the
possibility of improvements with new features... Yet I'm just a little
concerned about the recent additions of these new features.  It looks
like you've already begun ramping up for your experimental fork planned
for post 1.0.  It's definitely good to see you practicing for that! :D
But I'm worried that this is being done /before/ release 1.0.  Isn't bug
fixing supposed to be the highest priority now?

Okay... I'll keep quite, now.

-JJR
```
Feb 25 2006
Thomas Kuehne <thomas-dloop kuehne.cn> writes:
```-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright schrieb am 2006-02-26:
Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

http://www.digitalmars.com/d/changelog.html

Missing from the changelog:

added DMD Script Shell
http://www.digitalmars.com/d/rdmd.html

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFEAVhF3w+/yD4P9tIRAqh3AKCQdzlVeGTLvmBAM8hQlk01WFKUlACeIQ6R
pX7C/c/3ctdZ7xqjJ06VnqI=
=rLQz
-----END PGP SIGNATURE-----
```
Feb 25 2006
Dave <Dave_member pathlink.com> writes:
```In article <6r18d3-3l7.ln1 birke.kuehne.cn>, Thomas Kuehne says...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright schrieb am 2006-02-26:
Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

http://www.digitalmars.com/d/changelog.html

Missing from the changelog:

added DMD Script Shell
http://www.digitalmars.com/d/rdmd.html

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFEAVhF3w+/yD4P9tIRAqh3AKCQdzlVeGTLvmBAM8hQlk01WFKUlACeIQ6R
pX7C/c/3ctdZ7xqjJ06VnqI=
=rLQz
-----END PGP SIGNATURE-----

With an eye toward integrating rdmd with the compiler (as is mentioned in the
doc), if anyone has the time, please review the rdmd source code to spot any
potential security issues, subtle bugs, etc.

The most recent version of the source code (for both *nix and Windows) is here:
digitalmars.D.announce/2673

Thanks,

- Dave
```
Feb 26 2006
Thomas Kuehne <thomas-dloop kuehne.cn> writes:
```-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave schrieb am 2006-02-26:
In article <6r18d3-3l7.ln1 birke.kuehne.cn>, Thomas Kuehne says...

[snip]

Missing from the changelog:

added DMD Script Shell
http://www.digitalmars.com/d/rdmd.html

With an eye toward integrating rdmd with the compiler (as is mentioned in the
doc), if anyone has the time, please review the rdmd source code to spot any
potential security issues, subtle bugs, etc.

The most recent version of the source code (for both *nix and Windows) is here:
digitalmars.D.announce/2673

The argument parsing didn't seem to be very robust.

Thomas

begin 644 rdmd.zip
M4\$L#!!0`` `(`+*D6C1P;ETE0`T``+DJ```&`!4`<F1M9"YD550)``.``P)\$
M `,"1%5X!`#H`V0`M1IK;]O(\7,,Y#_L\$8%#7B5927NY(CH']=G*Q:AC&['2
M'.`S!\$I<26SX*I>4[";.;^_,[(/+ARPW:`U8%G=GY[7SI \.6![\$`>LSGV5Y
MNLS]F!4IFZ=Q%D:\Q^;^?,69GP2,W_)Y67!VHN'B,%D^W3LX8)&?+\$M_R9E(
MRWS.V0)."K8.?<;#8L5S!A^(,08T_2A,.\$MSY OFT^GGF>!ED#*QXE'\$Q#P/
ML^(Y2Q-V>7%U^CN<2Q9ICK3869B4MTS<B8+'8H"'"<&G/"P*GK#9'3OQUYR]
MC?R`SU)B.N<1]P4/6)B`5,A'5LZB<,Z"-/;#!+  %/PVB^`1X`#)JBBRUP<'
M\YS[1;CFR'B:B\$&:+P_ )\$\\$%P<2BT1B&)FL0 \$Z6!0;/^<,OH.BUF\$`6)VC
M*W9ZY1!+&]!)6A;P_0[IYEP(T`<A".,L" \$<SN=^4H1<](#Q>50&*+Y].`KC
ML`#V0\$U%VD-<A\$`=O&/I L4\GZ_ P9^%48A+.5Q,D2"Y!>H?R&=EGJ6"5ZI<
M\UP SA>#X=,]6GDY'+[J#U_V7[X"\4!<P?Y>\A5<X2\%/?[M,ST.YLD; O^1
MK?P\X,"JGR_+F"<%RWQ`JDSE1P8W"=2S-#>,+<);+I"<INY^"I, W0COZ=Z7
MIWL,U0+ 3!3!8#[8R#W]=X0'&5J)*!C(FU_?L'3V3SXOQK= %(3OD#D#6'-&
M+4BPZ3H8+"#8_=,]' FN]>%&:'F=[-"._'PT*X] Q&*"J#[)<G\9^VXLECWF
ME(DH,V0";.7BRO\$`^(E`<YB#00N>%^[0DPB>[M6XA<\HG/7H:4'^C=_BX"?Y
M!>QU#O8A'^`W3/77'"Y0P?C%BB3UHQ"L02\-!,_(\:\XW+=?I/FH!8(?"(9_
M;;"G>[,TC5#9,[!&\$'_A ]RT`6[+T,=<J2?0%)B5,0R&; T^7JS]"([U7XSD
M*J%;02Q`AC2^'IK]W\$:/H`;O/,[6/<2^'N\$ZV"JN`+0*A;DQ:"'!8\$L'3+-C
MX\0[14E[+\$`VY%>##.X8PJ[38T6<!2\$]'\!71QD18QW. ,M*;OPQ)XOTBB[(
M77(PH;7K3,;O+QW/4R+>:Y2#^"[Q8]0`*O%Z>&.( 68X!'H7U1GVM```-=+Z
M;M`.%V[(# _9T*O62/04PE92<H-9`3,7\`PBGBR+%7L#3A`X^FE_'VE</X,4
M9"\/!NS9#9+`18O*DZ]?V\C\$%FRB\$YUP/&9A1/=2;!J;^4%9B:?V\$.8)S_,T
M=YVXC(HPBQKI#D)^\AS\3#LF7*TT3/).=0^VJBS[+/)2VZ/^,38C;\O:M=#(
M\&#)86.PQ3FLQ+%!&B>,ZXC/8=;PDP9F8(F4V>]#ULX<KPV\$/Z6`JJ`#`<76
M&A9RS6UH-#O*?3NTU8U4!90=:*NP\P#B]NJ7;J2UJ#X7C!C17G_HC+I/2;8K
MDYZ+ACT/!P.S1F8\%UNDVL*7Y,T\$'\19\$2'G&&T_J#2U13\=MMVIC2*0VI!Q
MZ]&Z .S1TH59(UT4P7^O"Q,\\$6-%XO^BB7L[&%IB_H#8MK!.R>=;T_<["'1;
M)R6H;UM"A^\$'>=`QPN)#Q;GCM(P"C&F+\$,LYJ!=/=,B;IX&,>U:O `6FZA\$&
MM>!G:"E`5^J^I\VQ1X[=J[(DI6*5/;UV[C\$I&T`H7UN<RQ647)VW-G62:V2W
MM6<?DPJKY2X5(+RMD7:Q 0Z\$+UPH=\$!U/2<ODP32\6OF>(V[ZV)!\$=\=FAMD
MX%#/:9.X[^0M2M0QKVX.U0-U071[U=J6&J2#/U.#B<S?).O,E?6F*B 'T\OI
MIZ/32:^JB;34WY'8ZK3\+',UUNU(U9\*KUU'Y7?LBRF)!SF/TS77.+T1NX<F
MN)BOV)?[[2[2] 'FL&]6%O\&A4?-*VH7`,MEGJA=7;DK(Y%%&RRNTS!0A'6%
MF>?4\$&#9!M^3M"J,F_?>DVAZ#EAE3Y[37/#;L'#E<4V:2%'V=A]`Z7Q\$B-?&
M!-L`#(AIPNSZI*.6OF'7%HBUC+4UW4?`KEMU]LU6FEMY:=-XF'%9V?Q1_%%0
M6Q^#&8.P.XY0),,S;ZE6R;E*_;)3AZ;<CI_7`5_X4\$N")0<I2])"5C W.VBH
M<(14KE;IA 6\\\$%/..)8I\$ CS7A.!\$4'"0%'=E\$PY8H++<K7)7QX0"OC\W!Q
M5UVAC3L.=N%421_^3.'O%'VBP DKT"6GX(>03 1\X7+N%%0=%F2 5,Z2.#:T
M?A[RFGC8/'V'53CG:<%W6`*.Q\"O40\L+J&>F4&=F<BA5IGG..(HH>FFWH??
M%NS9Y='DW6.=(DA!#KH8V3BH\*',I9YP<:*&77GR6.2;,(I8FD3FUFJ#/-FW
MX\$2)^>SY(' N,SK7<PBG%B#&OY].IE<?CX_'5U<F3E"WH-.Z+O-D=C<UL,[R
MLK60N5YOVIUQO1\$/\$QQSU3OI+6W_T"1L`779O)CB*\$2BQF\CRFT=I0MNEH+<
M9E"AA:T<>WO<=2O^] V^JJ0Q+",\$RBDH*46A?;`V\$_%&S0F!Z `-ANMG_1>Z
M`-5"T6`'"A%[2*0*5D\IY(G<IH!I*N<.>-6*0B6MH(%>!UC5+MN;V`SK9KEB
M72,:TB'HNSOPH41/FM6G-I`XH)FP-6F!9,GZ_RI#7N FH5\$XP46/R%"\6J4&
MR]BY.\V.3Y.`^LZAO(SG-1M '.]/? +_B]'CVAE*0I6SNX)?OW %-ALNP0X4
M7W#*E0N]N2\*%Q/G]8VG"'HVD2K(X? 5P]A`NF!5BTO7T5?;,>FA&=&!5DJ]
M2 (\$\$HY,B"88MNE=#V\:6E%8OQVVYG:&9[A*VJ2Q\$8[AP;\$ &<Y\04O], SZ
M),.="/BZ#TX;\#YHTR"`Z QGP9:"U;N`AI(A2JGY/%D5T8.%A4JC.GR%=/Z.
M9B=H/\F2!SI&Z6F)%LN8*%A3'R_='I,!XZ[GM;>,EP]\$,061=H&`Q!6(-(2)
M`:1'3W)B/*(S6`&`"E6D-6D<,D[[LZVA" "J4*5KX'V%2X<:,`NIQ:]?V:X?
M("UAK:K%V(RD]C L))0L:CFVCK)L92X?+`>O(=WINZDLLJ;5N`CA_M]HM51+
M0!VQ-R,YF&3"-_2B"6D9O1GL6\$:0EM0(U'L\$E6(EW^!0_?%X"MJV'R3AR0&S
M=H.'L=NM;S.0U1H,UD\7CC0W:RD ZR6G&'U77VM5%U5GV[-"7\$<#5_5H]+;.
M-=#,EMSNZ>,T,#8\_'DX;/5(<\$RV9NJE"EV]W.KNX#H"0>-U3*.YJ_5B%,ZQ
M9/%<+0R.NW7E8WMO=?<R.RFCJ<J5+N!'EB5&P/8('E^MY<M\7;]5'-:XBH-&
M\<'>M`?VA\$''\$'V,[6LN[>M]L"FGUY\\Y\\%6T(U"[\$;JF0?/HH"['KCWPT&
M T92MJLGN*BJ>&J]SY`%M=>KO3C:,5M!<S>H=P]7:GJ09E-3'CP_K)WJ"IBK
MD+6U_<!0< ;<?QYU# ^W/-9'&UO,V)B;[NS;;S31D,PH19LP*(Z:"&:_>%L_
M4(&3\$L- 6N"GG-9_=FOC/US_`=_2=;Y.HE-UC34TA7%Q[1K.FI,>_`'32]D9
M)9MM<Z[-"GN5%]O)D#K(!QO(I70;*=[&#POXAFR#04CX'ALV&:*R'()HX\$H0
M;[<E&JWB07E*'^XPCRZSZ9 04W4<+A,_^BY6^N#\$,9S_'S%2I%`65GQ \,B*
MW(<PJ+K -GKKQ>+NZ?<CS*`Y<3,`\MAKXT12`1")QC ATY6W&O_Y";7NZ#RL
M5B1J*Z7B<%3? VP SZMA(,&P:YK`U2\$5`.[?M(:'G3-#;-[SQ#VN'!7]]T=F
M:()U:P2E6.'`05?#\$H5\_Z<NJ'(%CRRD(S>J2V3[;'B[6'CDPK<_+S"S:F3:
M[.K8.I'1=^2XCACPL3^Q%Y#`WM`G^AGB1XQ,F^8V9FMX*K:46S9.[93Q9R6C
MQ8#EIS8V ZFN(JAL4(R_CJ2YW;/JWVY,4-[^KS#R?NL#>771OUY<G+'?>/\$6
MXML\$:DSWW='YR=F8K=[2/WJ<7;X]/1M/3M^/690=T_\VI0G"];:\[:H=.`-M
M',UQED]'VIOX3UA\$5EN79N>CX/DY>,*1>W8YN9I\`/A?R\4"!T)GER>?+CZ<
ML.0J_+<ZIWP4&Q'_,U>%\$ZD4E\VC*:<L^<LH399,MFW:PN5]8)<V: !1&=Y-
M\$HJT19G,=?.C[]25GB2SHL4".I=]#]W_DJ(O`]9(^1QOY<B5V%"7T]_&Y^,/
MI\?3#^.C\$\ D/9:44=1C%Y?C\^GX]].KR>GY;PKT:#+Y</KKQ\EX>G[QX?W1
MF82M.C[FKC#3GI[_X^CL]&0J:4_AX>.XF7NK:[0OT41-Q&7;U\$JS)3_W:Z>J
MC&+E\$F\$U5H=U*H- \RY<KD[\!M'ZH5]^.61_?KEE\VL;Y5FZZ<#8JE6L['0<
M01OTSD\"*`Q65M_1V2<9T=K=\$5H#MD8F?E,&Z#D,%UMO?KJS4,,:97"NV:.J
MT'38MBQ/[<S(O10AZ6\$"'`QDESMZQG?(7OVE&A+47'6F/'0?#[9>P3;1()#1
MJA*IQD1=6L?IDI0ZP)J ]!)*-H;0/%2"WE.B^ ]02P,\$%``"`` `XJ1:-!E5
MEV3%`P``= L```D`%0!R9&UD+F1I9F955`D``]<#`D37`P)\$57 \$`. #9`"U
M5DEOVT84/LN`_\,K8;ABN9B48LFP*D.7GGK((0%Z<'R R)\$T#;?.C!0'COK;
M^]YPN&F)G:(=0!SR[?.]9>1Y'H D2[S0#_QD,`J"B1>,O-\$\$1L']>'K_;NP'
M]0(G"(/ PG&<6B4\I3*>'*DL%N"%H3NZ`P>W\006BPNXN;FD!^R8D+S(`2-`
MPN6% [2.T8^;(HLD_+YEFYS!KTI_+C[K3S_.'RJ%7V`3B83E"41BO<U8KJ",
MT&Z^KOD9SPL!92%4M.0I5U]AQ9^91#9ZK6,8_L'SI/ B;:2]X`^`9Z0"4B5^
M['^IN/4^T_%Z`#\$Z?WQ" RG[P-!OI-#5'*Q/GZQ95Z",U*8G,.OSB^6?+%:_
M/2N6ZW!0PD=:7X ]L[X\$\$DC"08DBE^H-Q Y%SYF\$/3IFJ62H0EN-TS#E^?;Y
M#\$B:5SU?!>CF%7SNWX#/]]%Y,S)OP47+[`T8N.'IG4\$IHG46#3.Y=L':YG);
M\$A L ?<?+)L4!E)%BL<02<F\$& :V09: 619%2J N"T1W#JL(#9-.#U%\IGSI
MZB^"L'K+DMOJI11%S*2L/O#'B_I58/T;&41VIFO=B5*._503?<G*?EYFQS+T
M(+E>?DQR_[M(R?\$9/-`1<.SI+.+YL\$H.I =;O>Y4FC"W8Q<'S"1TP[\$>,/7B
MJR&'^1P"^[(ETL)<*RQ3UI1I([_"!A^B>=?R\$\N&!U0&^/8-H,N0AF/KPFET
M ?A^RO*UVL`#D(7ZZ_J:8GZ\`J]']GVX>J((M;>.M0&Z/+(FSYB3)^U1D-US
MZY(UD6ZB':,LP4\&:;MF:JD!\$Z(00RO;IHJ7*":+K8B9KA:)GEG^,^:]+G?+
M!<'4+DJKFB<K^P.\&W]S4**"O;L2XE&)(1_/U67OJPQ/WU%NG;OI88H/LMIV
M<"RI;STO+K(2K8NY=>BUD[D>TK\$\ #GP_8:FT8VE?<;62Z>:CL.K(L&X9(GW
M4%5-<\M^#)]FG=Q_1X^B:</3V3YW*EKR,R_/0-[!]W4L55)AJ;(RX3^`)#;X
M\$9(-32.IDG^#9!7'C^+8:%\$D;6C_%XJF<L/)K3O%?S_3.S>\;4J71AH6O=C1
M(?"2&#8MX%[K5R+:9O[I?-2CCV2H(F1S_%:U-\WMF4&PO=),"U9JC:''*R]\
MPK&&``8- \$=*??%:S&SFGL/\=R]. [#]8J0&%9\,MC5R0J&>(E T1AQ]GI!K
MQUV7J4=9,^S:`]2F`JV&D_.\$17VNP=[\$NS^\$'^(,;[F<K#5-^3=8X/VUY4PU
M;;\$J!(OBC;FN\$!PQ0\URAY']`U!+`0(7`Q0`` `(`+*D6C1P;ETE0`T``+DJ
M```&``T```````\$```"D 0````!R9&UD+F155`4``X`#`D15>```4\$L!`A<#
M%``"`` `XJ1:-!E5EV3%`P``= L```D`#0```````0```*2!>0T``')D;60N
G9&EF9E54!0`#UP,"1%5X``!02P4&``````(`` "%````>A\$`````
`
end

-----BEGIN PGP SIGNATURE-----

iD8DBQFEAgSk3w+/yD4P9tIRAnqhAKCrgbSs/zGTwVZYVo2qZiBiQSo0twCeKKjM
UsbpRPYlvjigBibMLh7iZZI=
=BiW7
-----END PGP SIGNATURE-----
```
Feb 26 2006
Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
```Walter Bright wrote:
Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

Cool things added, cool things removed but when is bool going to be added?

<g>

;)
```
Feb 26 2006
Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
```Walter Bright wrote:
Lots of new stuff, I added new threads for them in the digitalmars.D
newsgroup.

http://www.digitalmars.com/d/changelog.html

FWIW, here's a(nother) practical example why bools-that-are-not-ints
would be useful.  I hit this bug in my own, real-world code, *TODAY*.

I am writing a small compiler.  In it, I build parse trees and
expression trees.  Some of these types had a field 'is_array'.  Today I
decided that it would be better to store the array length instead, so I
replaced 'is_array' with 'array_length in each struct.  I then had to
modify all of the code that used those fields.

In a dozens of places I had tests like:
if(expr->value.is_array)
which I needed to convert to
if(expr->value.array_length > 0)

Yet, in a number of cases, I ended up doing, instead:
if(expr->value.array_length);

Likewise, at least once I turned a test like
if(!expr->value.is_array)
into
if(!expr->value.array_length > 0)

Which are very hard to find...I'm just gradually finding these problems
as I run my test suite on the program.  They would have been compile
errors if bools and ints didn't have implicit casts between them.
```
Mar 07 2006