Spec#, nullables and more

[Simen kjaeraas]

Walter Bright <newshound2 at digitalmars.com> wrote:

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

There are some things that set non-null apart:

1. Few operations change the value of a pointer/class reference:
    assignment
    pointer arithmetic
    ref passing
Of these, the last two can be disallowed in most cases. For e.g. an
int, operator overloading adds bunches of more cases, and for structs/
classes where fields factor into the calculation, every single public
member function and field would need to be wrapped. Simply put, null
pointers are low-hanging fruit.

2. There is a single invalid value
This is a simplification, of course, as you could argue that a reference
to an A is not a valid reference to a B, and pointers may point to
arbitrary areas of memory, where nothing of interest may be found.
Again, low-hanging fruit.


>> 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.

Definitely a possibility, also for non-nullable. However, for such a
system to be foolproof (and that's what we want), we need a way to
disable the default constructor for structs.

There is also the problem of arrays, as I expounded on in a different
post. Without language support, this will be a hole in the system.

-- 
Simen