(non)nullable types

[Nick Sabalausky]

"grauzone" <none at example.net> wrote in message 
news:gn18a4$2c9c$1 at digitalmars.com...
>> Thus, trigger a run-time assert does not help AT ALL. Only a compile-time 
>> check will do.
>
> I wouldn't mind if the compiler only inserted assert()s for me. Having to 
> write these assert()s all over _and_ to write the documentation comments, 
> that a parameter must not be null, is the most annoying thing. Doing it at 
> runtime could save us from very annoying compiler behavior, and also 
> simplifies the compiler implementation.
>
> (Wasn't D supposed to be simple for the compiler writer? It seems everyone 
> forgot that, even Walter.)
>

I've been wondering about that too, as I certainly see the value in 
easy-parsing. However, whenever the ideals of "better error prevention" and 
"easy parsing" collide, I would much rather see the priority placed on 
"better error prevention". And I especially don't want to see a potential 
compile-time error left as a run-time error just for the sake of easier 
parsing. If easy parsing was my biggest concern, I'd just use an early 
version of ECMAScript (and I hate ECMAScript, especially the earlier 
versions).

> By the way, I wouldn't suggest to make non-null the default. This would 
> probably be too big of a language change. Instead, I'd propose to 
> explicitly mark non-nullable reference with "!" (similar to "?").

Another one of the points of D (unlike C++) is to avoid being buried under 
poor language design choices by not being afraid to break backwords 
compatibility when it's the only way to fix a problem in the language's 
design. I'm convinced that D hasn't reached a point where making 
nun-nullable the default would be too much of a problem.