Spec#, nullables and more

[Adam Burton]

Walter Bright wrote:

> 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.
Unfortunately I do seeing it as special. I can see why you don't and if D 
doesn't get non-nulls it is not like I am gonna run away crying but in my 
opinion it is different to values like 25.
> For example:
> 
>      NonNull!T p;
> 
> v.s.
> 
>      nonnull T p;
> 
> or worse:
> 
>      @nonnull T p;
> 
If someone is clever enough to figure out a way to do it without changing 
the compiler then that works for me too. It's not the idea of a compiler 
change I'd personally want, it's the feature. However as far as I can see 
the best way to implement it is a compiler change.
> 
>> 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.
> 
Agreed. However null is language defined and forced on all user defined 
class types. Most of the time I don't want/need it and having it entails 
more work in one way or another. Sometimes I do want/need it but that's a 
much smaller case than when I don't so I'd personally like to say when I 
want it.
> 
>> 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.
Agreed. If a resolution can be identified for the root problem then that is 
even better. While we can't I don't see why this common check can't be 
*almost* eliminated.