floating point - nan initializers

[John Stoneham]

Walter Bright wrote:
> I've also heard from people who do serious numerical work that, at last, D 
> is a language that cares about numerical analysis and its needs. Default 
> initializing to nan is part of that - it forces the user to *think* about 
> what he wants the initial value to be. Initializing it by default to 0 means 
> that it can easilly be overlooked, and 0.0 can introduce undetected, subtle 
> errors in the result.
> 

I agree. I'm currently working on an involved combinatorial calculation, 
and having one of the doubles auto-initialized to NAN help me find a bug 
in one of the calculations which would have been very difficult to find 
otherwise.

I say keep it.


> There is a 'nan' value for pointers - null, a 'nan' value for UTF-8 chars - 
> 0xFF - which is an illegal UTF-8 character. If there was a 'nan' value for 
> ints, D would use it as the default, too. 
> 
> 

There *is* a way get this behavior, and it can be done at compile time: 
raise an error when an int is assigned an initial value which cannot be 
calculated at compile time. This behavior could even be turned on with a 
command-line switch, -nan, or whatever.

For example:

int x = 1;
int y, z;
// initialization:
y = 7; // this is obviously ok
y = x; // this would also ok
z = abs(y); // this would raise an error, requires runtime evaluation

Or, even better, raise an error when the initialization value isn't a 
numeric literal. This would probably be even more consistent with the 
floating-point NAN behavior.