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