On 2014-02-04 04:26:22 +0000, Walter Bright <[email protected]> said:
On 2/3/2014 8:17 PM, Michel Fortin wrote:
That's not the case for nullable.
Yes, it is. If the function accepts a pointer to S and returns a
pointer to S.f, then a null pointer in means a null pointer out, and a
completely different type.
For that to happen you'd have to have a function like this one:
class MyObject { OtherObject value; }
OtherObject? foo(MyObject? o)
{
if (o)
return o.other;
else
return null;
}
The corresponding not-nullable version would be like that (notice the
efficiency gain):
OtherObject foo(MyObject o)
{
return o.other; // no need to check for null here
}
Honestly, I don't think writing accessors that check for null is that
common, except to detect null pointers passed in error because of the
lack of static checking. In general for an accessor it's better to let
the parent function check for null and only implement the later version
of the accessor. The parent function can do one null check before
calling all the accessors it wants, and accessors don't have to check
for null. You lose that efficiency if each accessors has to check for
null.
For the rare cases where you actually want both versions to work, you
can write them twice or use a template (except in a virtual context),
and in both cases you keep the efficiency of not checking for null when
the argument is not nullable.
In any case, I have yet to understand why @nullable as a storage class
would be any better. How do you solve that problem with a storage class?
--
Michel Fortin
[email protected]
http://michelf.ca
