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/epjwwtstyphqknavy...@forum.dlang.org
-- Simon
