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.
