Bools reloaded

[xs0]

Don Clugston wrote:
> Tom wrote:
>> In article <du9cnl$2h9j$3 at digitaldaemon.com>, Bruno Medeiros says...
>>> Don Clugston wrote:
>>>> Tom wrote:
>>>>> In article <du71jc$1e9h$1 at digitaldaemon.com>, Bruno Medeiros says...
>>>>>> Walter Bright wrote:
>>>>>>> "Tom" <Tom_member at pathlink.com> wrote in message 
>>>>>>> news:du049t$2uv2$1 at 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