Shouldn't bool be initialized to 0xFF ?

[Lionello Lunesu]

Bruno Medeiros 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.
> 
> You are right that it would be more consistent to have a "Not a Bool" 
> value. But this should not be implemented because of performance 
> implications: It would slow down conversions from int to bool, as well 
> as any kind of bool access/use, where a check for Not A Bool would have 
> to be made (and an exception thrown when necessary).
>   b1 == b2   // has to check if b1 or b2 is NotABool
>   if(b1)  // has to check if b1 is NotABool

Actually, you've raised an interesting point!

Just as float NaN is not equal to anything, a 0xFF bool would neither be 
false, nor true.

I don't think that anything else is needed besides the changed 
initializer. Float NaNs are not being checked anywhere. They just sit 
there until they're overwritten, or they appear (in output or debugger) 
and then you'll know that something is wrong.

Of course, there could be an option to make sure that a bool is either 
true or false, but I don't see this as a necessary implication of the 
original suggestion.

L.