[article] Language Design Deal Breakers

[Diggory]

Bugs occur when two parts of the program make slightly different 
assumptions about the interface between them.

Semantically checking those assumptions will always help, but it 
will also always be limited. The idea that code will always 
branch on nullable types and handle both cases is wishful 
thinking. 90% of the time a null pointer is caused by one of the 
following:

Problem: I don't know how to handle a null value here
Solution: Either pass on null-ness or assert not null

Problem: I know this returns a nullable but because of XYZ I know 
it can never be null
Solution: Assert non null

Both of these are caught at runtime just the same as a null 
pointer exception would be. The only concrete benefits of 
nullable are for annotation, and making sure that the exception 
is thrown at the point where the assumptions in the program 
differ rather than at some point further down the line.

Of course this is definitely good and useful, but it's not the 
golden bullet people say it is.

There is also a way we could get non-nullable types in D without 
breaking any existing code. There could be an attribute or marker 
interface for classes/interfaces that says the default for that 
class is for it to be non-nullable. Being able to specify this 
with the colon syntax for the entire module would be nice too.

It could still be nullable explicitly using 
Nullable!T/Some!T/Optional!T

The only difficulties are at the boundary between the first 
nullable base class and its derived non-nullable class in the 
type hierarchy. Fixing it should be just a case of making 
down-casts convert to Nullable!T instead of T, and making 
up-casts convert to both NotNull!T and T.

In the event that this becomes popular, D could transition 
smoothly to the new system by first making NotNull a compiler 
switch to change the default, then deprecating implicitly 
nullable types, etc. giving plenty of time to switch over.