On 8/11/2012 1:57 AM, Jakob Ovrum wrote:
The compiler in languages like C# doesn't try to prove that the variable is NOT
set and then emits an error. It tries to prove that the variable IS set, and if
it can't prove that, it's an error.
It's not an incorrect diagnostic, it does exactly what it's supposed to do
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.
In D, on the other hand, it's possible to write D code like:
for(size_t i; i < length; ++i)
{
...
}
And I've actually seen this kind of code a lot in the wild. It boggles my mind
that you think that this code should be legal. I think it's lazy - the intention
is not clear. Is the default initializer being intentionally relied on, or was
it unintentional? I've seen both cases. The for-loop example is an extreme one
for demonstrative purposes, most examples are less obvious.
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?
Saying that most programmers will explicitly initialize floating point numbers
to 0 instead of NaN when taking on initialization responsibility is a cop-out -
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.
float.init and float.nan are obviously the values you should be going for. The
benefit is easy for programmers to understand, especially if they already
understand why float.init is NaN. You say yelling at them probably won't help -
why not?
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.
