DMD 0.148 release

[Ivan Senji]

Walter Bright wrote:
> "Ivan Senji" <ivan.senji_REMOVE_ at _THIS__gmail.com> wrote in message 
> news:dtuatr$l0k$1 at 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.