Adventures in D programming | Hacker News Reader

Adventures in D programming

blog.tenstral.net

I recently started using D and I was loving it so far. I bought Alexandrescu's excellent The D Programming Language. It's a fun book, teaches a lot about programming in general, and even if you don't think you'll use D, I recommend reading this book to get ideas about what programming languages can do.

Then I ran into this:

https://issues.dlang.org/show_bug.cgi?id=15994

The response to this has almost completely demolished my interest in D. It is with a broken hacker heart that I think I need to step away from D. The problem is not that it's possible to segfault in D or dereference a null pointer in D, as Rust allows this too, but that it's so easy to do so. The worst part is that the response is to blame the learner instead of blaming the language. If I wanted to be blamed, I would go back to C++.

I tried to suggest a language change in IRC, such as for example disallowing bare "SomeClass someobject;" declarations and requiring either "SomeClass someobject = new SomeClass(foo, bar, baz)" or "SomeClass someobject = null;" in order to make it explicit that the reference will be null, but everyone in IRC seemed to think that it was impossible to change the D language. This despite how the language is already constantly changing because as blog post mentions, Phobos is rapidly changing.

I am going to try to raise this concern again in the D mailing list/forum (it's actually really cool these two are the same thing). There are so many good ideas in D, and I really loved everything up until I ran into this. Maybe Walter or Andrei will see the importance of making it more difficult to dereference null pointers.

Looking at this from a Java perspective, the behaviour of the example attached to the bug is valid.

It would be a significant improvement if it gave a warning when an uninitialized variable is used, but apart from that I wouldn't make any changes here.

The comparison to Java isn't quite right, as D has structs which are like classes can be on the stack and classes which must always be a reference. So there's a bit of a syntactic inconsistency, where you might think that "SomeClass object;" would declare an object on the stack like "SomeStruct inst;" would, whereas instead it only declares a null reference.

If classes can only be references, the syntax should enforce that more clearly. In Java, everything is a reference, so there is less inconsistency there.

Yeah, it's not a perfect comparison. I only chose it because I'm familiar with it and understand how that style of code would behave.

I do agree that reading a line like "Blah varName;" is confusing when you don't know what 'Blah' is.

Reply on news.ycombinator.com