Disallow null references in safe code?

[Jonathan M Davis]

On Monday, February 03, 2014 22:03:13 Andrei Alexandrescu wrote:
> On 2/3/14, 9:09 PM, Jonathan M Davis wrote:
> > I truly hope that that's never the case. Adding non-nullable references to
> > the language is one thing; making them the default is quite another, and
> > making them the default would break existing code. And given Walter's
> > normal stance on code breakage, I'd be very surprised if he were in favor
> > of making non- nullable references or pointers the default.
> 
> We are considering making non-nullables the default, @nullable to mark
> optionally null objects, and enable the related checks with an opt-in
> compiler flag.

So, the default is going to be non-nullable except that it isn't really non-
nullable unless you use a flag? That sounds like -property all over again. It 
could certainly be used to smooth out the transition, but we'd have to be way 
more on top of it than we've been with -property and actually get all of the 
checks ironed out and make it the default within a reasonably short period of 
time rather than years of it going almost nowhere. And if the suggestion is 
that the flag be around permanently, well, I don't see that as turning out any 
better than it has with -property (which has essentially been permanent in 
that it's functionality has never been fully integrated into the language nor 
has it gone away with its functionality not being integrated). That would 
essentially be forking the language. So, I can only assume that it's not the 
intention that the flag be permanent but rather that it's intended that it 
eventually become the default behavior. That can be made to work, but we don't 
have a good track record on this sort of thing.

Also, completely aside from whether it's the default, how are we going to deal 
with all of the many cases than require an init value? Does it effectively 
become the class equivalent of @disable this()? While @disable this() might be 
a useful feature under certain circumstances, it has a lot of nasty 
repercussions - particularly with generic code - and IMHO one of the biggest 
warts in the language. It may be a necessary one, but it's still a wart, and 
one that definitely causes actual problems rather than being a matter of 
aesthetics.

So, making non-nullable references the default would be akin to making 
@disable this() the default for structs. It's not quite as bad given that 
structs are probably more commonly used than classes in D, but it looks to me 
like it's essentially the same thing. And that seems like a really bad idea, 
just like making disabling structs' init value by default would be a bad idea.

And are you thinking of this for references only, or are pointers going to 
become non-nullable by default as well? That could cause some grief with 
extern(C) functions, given that they're going to need to take nullable 
pointers, and it could make interacting with AAs more annoying given that 
their in operator returns a nullable pointer and that that pointer must be 
nullable for it do it's job.

This whole thing seems like a really bad idea to me. Having non-nullable 
pointers or references can certainly be useful, but it doesn't fit well with 
D's design with regards to init values, and making them the default seems like 
a disaster to me.

And if we were going to start changing defaults, I would have thought that 
making pure, @safe, and/or nothrow the default would be a lot more beneficial 
given how they have to be used absolutely everywhere if you want to do 
anything with them.

- Jonathan M Davis