Spec#, nullables and more

[Walter Bright]

Adam Burton wrote:
> I *think* I undertand what you mean, however I also think I failed to 
> explain myself correctly. After reading bearophiles post I think he put it 
> in much better terms of null being a common case that is handled in common 
> way.

I don't see that non-null is such a special case that it would benefit from a 
special case syntax. For example:

     NonNull!T p;

v.s.

     nonnull T p;

or worse:

     @nonnull T p;


> The value 25 requires far more context for the compiler to identify it 
> as a bad value and determine how the developer should handle it.

The compiler wouldn't do it. It would be a user supplied filter for a user 
defined subtype.


> The non-nullable propsal doesn't eliminate NPE but it allows you to narrow 
> the locations of the error. I know most of my code doesn't use nulls (you 
> might say I avoid them like the plague) but sometimes code calls for the use 
> of nulls, so if I can reduce the amount of code where a null can go then I 
> have much less code to debug.

The issue of null is only a small part of the possible space of subtyping checks 
one can find desirable in a program.