Shouldn't bool be initialized to 0xFF ?

[Kristian Kilpi]

On Tue, 15 Aug 2006 17:09:16 +0300, Oskar Linde
<oskar.lindeREM at OVEgmail.com> 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.
>
> 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.
>
> /Oskar

What if the compiler wouldn't enforce the value to be 0 or 1 in bool.init?
This way the initial value could be 0xFF indicating that a variable is not
initialized by the user.