[article] Language Design Deal Breakers

[Jonathan M Davis]

On Monday, May 27, 2013 09:27:58 deadalnix wrote:
> What need to be added to the language to make the lib work is
> equivalent to what is needed to make it the default (Make the
> compiler track initialization), and is also required for other
> aspects of the language (initialize immutable objects).

I don't see why. NotNull would statically prevent assigning null to it (which 
is easy to do, since null has its own type) and will assert that any 
references assigned to it are null. You then have the guarantee that NotNull!T 
is never null. What would a built-in type do that that doesn't? The one point 
where null could get in - when constructed from a nullable reference - would 
have to be checked with a built-in type as well. The only way to prevent it is 
to make it illegal to assign a nullable reference to a non-nullable one and 
make it so that construction has to occur within the the non-nullable 
reference - e.g. NotNull!T(args).

> and most modern languages try as hard as possible to get rid of it

Sure, some languages try and get rid of it, but for most part, major languages 
do not. If we were starting from scratch, then maybe it would be worth making 
non-nullable the default, but I completely concur with Walter that the issues 
with nullability are being blown way out of proportion. Sure, dereferencing 
null happens, but there are a ton of other bugs that are far more common. And 
with NotNull, you have a non-nullable reference.

- Jonathan M Davis