Smart pointers instead of GC?

Michel Fortin michel.fortin at michelf.ca
Mon Feb 3 19:24:36 PST 2014


On 2014-02-03 19:53:58 +0000, Walter Bright <newshound2 at digitalmars.com> said:

> On 2/3/2014 3:45 AM, Michel Fortin wrote:
>> As for writing functions twice, I don't see it. T is implicitly convertible to
>> T?, so a single function with a T? parameter will work with both T and T?
>> arguments.
> 
> It's the same issue as with const (which we dealt with by adding the 
> 'inout' qualifier). It's the affect of the argument type on the return 
> type.

Const can represent either mutable or immutable data, so you have inout 
standing in as "same output as input". This is useful, necessary even, 
if your function returns some part of its input, like the value of a 
field.

In theory it could make sense to have something similar for nullable, 
where you have a qualifier standing for as "same nullability as input". 
That said, you can't return a part of the input if the value is null, 
and that part's nullability won't depend on its parent (nullability is 
not transitive), so it's not as useful. The only useful thing that 
comes to mind is a function where you return the passed argument 
directly, such as this one:

	Object? foo(Object? o)
	{
		if (o)
			writeln(o);

		return o;
	}

But, you could implement this as a template function if you absolutely 
need to transfer nullability, and the template will actually make 
things more efficient because the template instantiated with a 
non-nullable function argument will optimize away the unnecessary 
branch.

And to get to the root of this, I think it'd be much more useful to 
have a "same type as input" stand-in, because notice how in the above 
function if you pass a DerivedObject, you'll get an Object returned, 
losing the derived part? Exact same problem, and we've been living with 
it for decades.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca



More information about the Digitalmars-d mailing list