Shouldn't bool be initialized to 0xFF ?

[Lionello Lunesu]

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?

> 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.

Look at NaNs. Yes, they propogate, and if after a lengthy calculation 
you print the output and you see that you end up with a NaN, you know 
that you've used a NaN along the way. But how often do you print the 
output of such a calculation? Surely most of the time the numbers are 
simply used somewhere, a position of an object, the color of a pixel, or 
simply a comparison "if (f<0.4)...". How does a NaN show up in those 
situations? Not as a nicely printed "NaN", that's for sure.

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".

> 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.

How about this for consistency: similar to the floating point 
comparisons, the operators <>, !<>, <>=, !<>= could be used to check for 
"not a bool"? (don't ask me how exactly; I don't quite grasp the <> yet.)

L.