On Saturday, 11 August 2012 at 09:40:39 UTC, Walter Bright wrote:
Of course it is doing what the language requires, but it is an
incorrect diagnostic because a dead assignment is required.
And being a dead assignment, it can lead to errors when the
code is later modified, as I explained. I also dislike on
aesthetic grounds meaningless code being required.
It is not meaningless, it's declarative. The same resulting code
as now would be generated, but it's easier for the maintainer to
understand what's being meant.
That perhaps is your experience with other languages (that do
not default initialize) showing. I don't think that default
initialization is so awful. In fact, C++ enables one to specify
default initialization for user defined types. Are you against
that, too?
No, because user-defined types can have explicitly initialized
members. I do think that member fields relying on the default
initializer are ambiguous and should be explicit, but flow
analysis on aggregate members is not going to work in any current
programming language. D already works similarly to C# on this
point.
And for the record, I have more experience with D than C#. I
barely use C#, but I'm not afraid to point out its good parts
even though D is my personal favourite.
You can certainly say it's a copout, but it's what I see them
do. I've never seen them initialize to NaN, but I've seen the
"just throw in a 0" many times.
Again, I agree with this - except the examples are not from D,
and certainly not from the future D that is being proposed. I
don't blame anyone from steering away from NaN in other C-style
languages.
I do, however, believe that D programmers are perfectly capable
of doing the right thing if informed. And let's face it - there's
a lot that relies on education in D, like whether to receive a
string parameter as const or immutable, and using scope on a
subset of callback parameters. Both of these examples require
more typing than the intuitive/straight-forward choice (always
receive `string` and no `scope` on delegates), but informed D
programmers still choose the more lengthy, correct version.
Consider `pure` member functions - turns out most of them are
actually pure because the implicit `this` parameter is allowed to
be mutated and it's rare for a member function to mutate global
state, yet we all strive to correctly decorate our methods `pure`
when applicable.
Because experience shows that even the yellers tend to do the
short, convenient one rather than the longer, correct one.
Bruce Eckel wrote an article about this years ago in reference
to why Java exception specifications were a failure and
actually caused people to write bad code, including those who
knew better.
I don't think the comparison is fair.
Compared to Java exception specifications, the difference between
'0' and 'float.nan'/'float.init' is negligible, especially in
generic functions when the desired initializer would typically be
'T.init'.
Java exception specifications have widespread implications for
the entire codebase, while the difference between '0' and
'float.nan' is constant and entirely a local improvement.
