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.

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

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

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.

I'm not sure that "more crazy .init values" is the cure to char/float...

--anders

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.

Anders F Björklund 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.
> 
> I'm not sure that "more crazy .init values" is the cure to char/float...

Well, it would have helped me find a very old bug (a bool that wasn't inited).

L.

Lionello Lunesu wrote:

>> I'm not sure that "more crazy .init values" is the cure to char/float...
> 
> Well, it would have helped me find a very old bug (a bool that wasn't inited).

I'm glad that they help you all find bugs, I guess I'm just too old
and used to zero-as-initializer to get used to the D initializers...

Nothing to worry about. Maybe I will see the light, and like them ?
Glad the age-old bug with the array initializers* was fixed, though.

--anders

* i.e. the one where they were getting all zeroes, instead of .init

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.

void main() {
    bool b; // b is 0xFF
    if (b) { // Is b true or false?
        // ...
    }
}

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

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

Kirk McDonald 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.
> 
> void main() {
>     bool b; // b is 0xFF
>     if (b) { // Is b true or false?
>         // ...
>     }
> }
> 

void main() {
    bool b; // b is 0x00
    if (b) { // Is b true or false?
        // ...
    }
}

L.