> 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
