null [re: spec#]

[Wyrlon]

> I think it's reasonable to let the current references and pointers 
> continue to be as they are, and work on @disable (particularly its 
> interaction with constructors) to make it easy to implement restricted 
> subsets of values. Then NonNull would be a useful library artifact among 
> other ones.
>
>
> Andrei

Rather than focusing solely at NonNull, I'd prefer to return to the problem 
at hand and ask what alternate solutions are there?
For that reason I really like Andrei's approach, as it has far wider 
appliances.

Still I'd like to point out one other idea which I came across in the 
programming language 'E', it's extemely simple to implement yet solves many 
other problems which nonnull cannot.
http://blubbedev.net/e_guide_html/ch_13c.html

As I see it, the main problem is interoperability between 3rd party 
libraries... in contrast to within ones own framwork/program since 'D' 
already provides first class error handling mechanisms.

Basically it's just a "global" list of "function error return codes" 
translated into the exception of your choice, sure it is possible to wrap 
everything manually... but this mechanism makes it very easy to do the right 
thing and _keep_ the old naming convention of the 3rd party library and 
still benefit from improved automatic error handling...

Teoretically one could specify it already when importing the function with 
"extern C" etc... but it probably would require too many manual adjustments 
to be really useful... well just _throwing_ the idea in here. ;)

Wyrlon