An alternative to .init

[JAnderson]

Benji Smith wrote:
> Walter Bright wrote:
>> Andrei Alexandrescu wrote:
>>> I hear you. I brought up the same exact design briefly with Bartosz 
>>> last week. We called it T.invalid. He argued in favor of it. I 
>>> thought it brings more complication than it's worth and was willing 
>>> to go with T.init for simplicity's sake. Why deal with two empty 
>>> states instead of one.
>>>
>>> One nagging question is, what is T.fail for integral types? For 
>>> pointers fine, one could be found. For chars, fine too. But for 
>>> integrals I'm not sure that e.g. T.min or T.max is a credible fail 
>>> value.
>>
>> The T.init value should be that. That's why, for floats, float.init is 
>> a NaN. But for many types, there is no such thing as an invalid value, 
>> so it really doesn't work for generic code.
> 
> I don't think values necessarily have to be initialized to an invalid 
> value. You could certainly argue that NaN values are valid results of 
> certain computations, and that they're valid in certain contexts.
> 
> The important thing is that they're *uncommon*, and if you see them 
> cropping up all over the place where they shouldn't, you know you have 
> an initialization problem somewhere in your code.
> 
> The same thing could be true for integers, but zero is such a common 
> value that it's tough to spot the origin of the error.
> 
> If signed integers were initialized to min_value and signed integers 
> were initialized to max_value, I think those initialization errors would 
> be easier to track down. Not because the values are illegal, but because 
> they're *uncommon*.
> 
> --benji

I agree.  I use the 0xcdcdcdcd and 0xfefefefe provided by MSVC a lot to 
track down errors.

-Jowl