DMD 0.148 release

[Derek Parnell]

On Mon, 27 Feb 2006 02:43:56 +1100, Wang Zhen <nehzgnaw at gmail.com> wrote:

> Derek Parnell wrote:
>> On Sun, 26 Feb 2006 17:29:03 +1100, Wang Zhen <nehzgnaw at gmail.com>  
>> wrote:
>>
>>> Derek Parnell wrote:
>>>
>>>> On Sun, 26 Feb 2006 12:54:15 +1100, Walter Bright    
>>>> <newshound at 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