Which D features to emphasize for academic review article

Walter Bright newshound2 at digitalmars.com
Sat Aug 11 02:40:22 PDT 2012


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.





More information about the Digitalmars-d mailing list