Shouldn't bool be initialized to 0xFF ?

[nobody]

Lionello Lunesu wrote:
> nobody wrote:
>> Lionello Lunesu wrote:
>>> I've been following those "why's char init'ed to -1?" / "why's float 
>>> init'ed to NaN?" thread, and I'd have to agree with Walter: a crazy 
>>> initialization sure makes it obvious where the problem lies.
>>>
>>> So: why isn't "bool" initialized to 0xFF too? In dmd v0.164, 
>>> bool.init is 0, which is a valid value for bool. For byte/int/long I 
>>> get it, since there is no invalid value for byte/int/long. But for 
>>> bool there is, so the same reasoning as char/float applies.
>>>
>>> We could even name 0xFF "Not A Bool" ;)
>>>
>>> L.
>>
>> I understand why this idea might seem appealing but I am fairly 
>> certain it is ultimately a bad idea.
>>
>> The two examples you gave are different from bool.
>>
>> In the case of the reals the reason so much care is taken to assure 
>> NaNs propogate freely is because (unlike any other basic type) the 
>> result of almost any real valued operation which has valid arguments 
>> may not be representable as a real number. Using NaN as a default 
>> initializer is merely an elegant side effect. NaNs require special 
>> treatment however. 
> 
> The propogation of NaNs is indeed a nice feature, and it might be nice 
> to note that operator | propogates 0xFF-bools in a similar fashion (& 
> does not, though, and ^ can result in yet another invalid boolean value).
> 
>> So the 'undefined' bool value 0xFF will be converted just like a char 
>> or ubyte and will evaluate as true! Certainly this behavior is even 
>> worse than having a default of false?
> 
> This I don't get. How's having a default of false better than having a 
> default of true?

I can see why this might not be obvious if you do not much of a background with 
C style languages. In most C style languages (C, C++, Java and D) pretty much 
anything is 'true' if it is non-zero because 'truth' can be determined by simply 
testing for inequality with the constant 0. Thus the only default initializer 
which works the same for "pretty much anything" is a zero bit pattern. I think 
it is impossible to stress enough how ingrained this reality becomes. The best 
example of exactly how ingrained it is would be my implicit assumption that 
anyone else would see the folly of a default value evaluating true.


> 
>> One might imagine it should be possible to change the way if 
>> expressions work. Except you would also have to change the equivalent 
>> for, foreach and while conditionals as well. The worst part is that 
>> the general case of conditional expressions are in fact testing 
>> relations on non-bool values -- so most of the time you will be 
>> testing to see if you should throw an Exception for bool's 'undefined' 
>> value in cases where it is not even possible.
> 
> I don't see checking for invalid boolean values as a necessity, let 
> alone throwing an exception.
> 
> ...
> 
> The power of the funky default initializer lies in the debugging, not in 
> it's 'default behavior'. Yes, it's _handy_ to have bools initialized to 
> false, since that's a useful value. It'll save you typing. But it's an 
> arbitrary choice. In 50% of the cases you'll want an initializer of 
> 'false', and in the other 50% you'll want 'true'. In the first cases you 
> don't type anything (since the default is false, handy) and in the 
> latter cases you'll have to implicitly type the "= true".

Again this runs deeper than just typing one random thing instead of another. It 
is about a deeply ingrained way of looking at the world. Your 50% figure is 
based on the assumption of random distribution which may seem close enough to 
true for you. In the case of people coming to D from other C style languages the 
figure is probably very close to 100% of case wanting false.


>> A further problem I see comes from my (possibly wrong?) belief that 
>> bit[] has become bool[]. If bool[32] occupies 4 bytes as I believe 
>> then in this case there is no room for bool's 'undefined'. So then one 
>> must ask what value should be bools default in this case?
>     
> bit is gone, and bool is similar to C++'s bool. bool.sizeof==1, and a 
> bool[32] needs 32 bytes.

Do you know why it was eliminated? Or perhaps have some idea of when? Or even a 
general spot to start looking in posts to find out why myself?