An alternative to .init

[Benji Smith]

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