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