SafeD and Nullable concept

Steven Schveighoffer schveiguy at yahoo.com
Thu Jan 15 06:42:55 PST 2009


"Denis Koroskin" wrote
>I think I have found one more reason for Nullable concept to appear in D:
>
> Since SafeD disallows pointers, it needs something safe to replace them.
>
> For example, it is impossible to use AA in SafeD, because opIn_r returns a 
> pointer:
>
>> Foo[Bar] aa;
>>
>> Bar bar = new Bar();
>> Foo* fooPtr = bar in aa; // this line is disallowed in SafeD
>
> I wonder why it returns a pointer, and shouldn't it return Nullable!(Foo) 
> (or just Foo? as an alias) instead?

Because you can change the value, not what the value poitns to.  For 
example, in an AA, if I want to replace the object found at a specific key, 
I need a reference to the class reference, i.e. a pointer.

I think what might be useful is to make references nullable (and have some 
operator to determine if that is the case), and use references instead of 
pointers wherever a null return value is a possibility.  The danger of 
pointers is that you can willy-nilly point them to any memory location. 
References stick to where they were set (and in SafeD, cannot be created 
with pointer arithmetic).

so something like:

ref Foo fooPtr = bar in aa;
if(fooPtr !is nullref) // new keyword
{
 ...
}

or

if(fooPtr !refis null)

or with no new keywords:

if(ref fooPtr !is null)

>> Foo? foo = bar in aa; // null, if item is missing
>
> Note that now it became slightly more efficient, because we don't need an 
> additional pointer dereference, which was present when we returned Foo*!

Then how do you change the value at that location?  To further demonstrate 
the point, imagine Foo is a struct, not a class.

-Steve 





More information about the Digitalmars-d mailing list