Which D features to emphasize for academic review article

[Jakob Ovrum]

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.