On Monday, 27 May 2013 at 06:59:31 UTC, Jonathan M Davis wrote:
On Monday, May 27, 2013 08:49:37 Rob T wrote:
So will introducing non-nullable references make things worse or
have no practical effect?

We're going to add non-nullable references as a library type (NotNull!T or NonNullable!T or somesuch). That will allow you to type references as being non-nullable. It doesn't give quite as high a gain as having them being a built-in type, but there's a definite cost to adding something to the language (far higher than adding it to the library), and we don't think that the cost
is worth it.


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).

If I do agree that the cost in regard to code broken is high (and probably prohibitive) the cost in term of language complexity isn't what you claim it is.

Additionally, safe behavior are either Nullable, with obligation to handle the null case from the user (which is easy to provide as a lib in D) or NonNullable. The default is the worst of both world, as it is nullable, without any obligation to handle that case and simply causing the program to crash (plus it will require runtime checks to make things @safe).

Again, it's not the case that null references aren't a problem. It's just that they're being blown of proportion, and it's just not worth adding a built-in type to deal with them at this point (let alone making references in general non-nullable by default as some people would like done). You don't add new features to a language to solve every bug that comes along. We have a powerful language. Let's take advantage of it. The library solution should be fine. It
just isn't as extreme a solution as some people would like.


Many people here have expressed real problem with null, a lot of documentation on the web exists about it as well, and most modern languages try as hard as possible to get rid of it (even sometime in creative way as scala does as they can't get rid of it completely because of java compatibility).

Reply via email to