floats default to NaN... why?

[F i L]

So it's what I thought, the only reason is based on a faulty 
premise, IMO.

Jonathan M Davis wrote:
> Types default to the closest thing that they have to an invalid 
> value so that
> code blows up as soon as possible if you fail to initialize a 
> variable to a
> proper value and so that it fails deterministically

This seems like exactly opposite behavior I'd expect from the 
compiler. Modern convenience means more bang per character, and 
initializing values to garbage is the corner case, not the usual 
case.

> (unlike when variables
> aren't initialized and therefore have garbage values).

This is the faulty premise I see. Garbage values are a C/C++ 
thing. They must be forced in D, eg, float x = void.

I would argue that because values *should* have implicit, 
non-garbage, default values that those default values should be 
the most commonly used/expected "lowest" value. Especially since 
ints _must_ be 0 (though I hear this is changing in Arm64).


> NaN is the invalid value for floating point types and works 
> fantastically at
> indicating that you screwed up and failed to initialize or 
> assign your
> variable a proper value.

> null for pointers and references works similarily
> well.

Not exactly. NaNs don't cause Segfaults or Undefined behavior, 
they just make the math go haywire. It's like it was designed to 
be inconvenient. The argument looks like this to me:

"We default values so there's no garbage-value bugs.. but the 
default is something that will cause a bug.. because values 
should be explicitly defaulted so they're not unexpected values 
(garbage).. even though we could default them to an expected 
value since we're doing it to begin with"

It sounds like circular reasoning.


> It was never really intended that variables would be default 
> initialized with
> values that you would use.

why exactly? again, this is a faulty premise IMO.


> You're supposed to initialize them or assign them
> to appropriate values before using them.

sure, but if they always default to _usable_ constants no 
expectations are lost and no bugs are created.


> Now, since the default values are
> well-known and well-defined, you can rely on them if you 
> actually _want_ those
> values,

yes, and how often do you _want_ a NaN in the mix? You can rely 
on usable values just as much. Even more so since Ints and Floats 
would be consistent.


> but the whole purpose of default initialization is to make code 
> fail
> deterministically when variables aren't properly initialized - 
> and to fail as
> quickly as possible.

that only makes sense in C/C++ where value are implicitly garbage 
and mess things up.


Again, this is only my perspective. I would love to hear 
convincing arguments to how great D currently defaulting to NaN 
is, and how much headache (I never knew I had) it will save me... 
but I just don't see it. In fact I'm now more convinced of the 
opposite. Never in C# have I ran into issues with unexpected 
values from default initializers. Most important values are set 
at runtime through object constructors; not at declaration.