Why does nobody seem to think that `null` is a serious problem in D?

[SimonN]

On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez 
Hermoso wrote:
> When I was first playing with D, I managed to create a segfault

> What's the reasoning for allowing this?

100 % agree that there should be non-nullable class references, 
they're my main missing feature in D. Likewise, I'm astonished 
that only few D users wish for them.

I understand that it's very hard to get @safely right, without 
code-flow analysis that Walter prefers to keep at minimum 
throughout D.

I'm concerned about the clarity of usercode. I would like to 
ensure in my function signatures that only non-null class 
references are accepted as input, or that only non-null class 
references will be returned. All possibilities in current D have 
drawbacks:

a) Add in/out contracts for over 90 % of the class variables?
This is nasty boilerplate.

b) Check all arguments for null, check all returned values for 
null?
This is against the philosophy that null should be cost-free. 
Also boilerplate.

c) Declare the function as if it accepts null, but segfault on 
receiving null?
This looks like a bug in the program. Even if c) becomes a 
convention in the codebase, then when the function segfaults in 
the future, it's not clear to maintainers whether the function or 
the caller has the bug.

I discussed some ideas in 2018-03:
https://forum.dlang.org/post/epjwwtstyphqknavycxt@forum.dlang.org

-- Simon