Smart pointers instead of GC?

[Michel Fortin]

On 2014-02-04 04:26:22 +0000, Walter Bright <newshound2 at digitalmars.com> 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
michel.fortin at michelf.ca
http://michelf.ca