Shouldn't bool be initialized to 0xFF ?

[Lionello Lunesu]

Oskar Linde 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" ;)
> 
> There is a difference here. For char, 0xff is a valid value. That is, 
> the spec says a char may hold the value 0xff - possibly to represent an 
> illegal character. Likewise for NaN. NaN is a well defined value for 
> floating point types. It is within the types value range.

For float, I'd have to agree with you.

But, for char, the spec says it's an UTF8 string, and 0xFF is clearly 
invalid in UTF8. The 'physical storage' of char allows for the 0xFF to 
be used as a initializer to catch uninited data. And I guess the same 
can be applied to bool.

 > A bool may never hold any other value than 0 or 1. This is enforced by
 > the compiler. No other value than 0 or 1 is within the bool value
 > range. The bool is the only type I know of where the compiler forces a
 > value range below the possible physical storage range.

You're citing the spec, when I'm actually suggestion an addition to the 
spec. Sound like a logical fallacy to me (but which one? anyone?)

L.