An important potential change to the language: transitory ref

[Michel Fortin]

On 2010-03-20 18:24:58 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

>> That could work. It'd only become a hindrance in the more complex cases
>> where you have multiple ref arguments in a function and no way to tell
>> which one the returned ref comes from.
> 
> Yes. Conservatively, the scope of a returned ref is the smallest of all 
> parameters involved, including 'this'.
> 
> There are two touches that Walter and I discussed:
> 
> a) You only need to keep in that set the parameters with .sizeof 
> greater than or equal to the return type;
> 
> b) You only need to keep in that set the parameters that contain a 
> direct subobject of the return type.
> 
> The rules are a bit odd, but they do the job and most importantly 
> enable important encapsulation mechanisms.

Not only odd, but hard to predict.

The problem with those rules is that if the definition of a struct 
changes in subtle ways your program might stop compiling.

If a struct on Linux is larger than the equivalent struct on Mac OS X 
and this prevents some code from compiling, what are your options? 
Refactor your program to use pointers? If some generic algorithm 
accepts two arguments of any type but which can only return the first 
argument, should certain ways of calling it become unusable as soon as 
you give it two arguments of the same type?

That kind of attempt at cleverness sounds like a lot of annoying edge 
cases waiting to be found. I think it's bad coupling that if you add a 
never-used private member to a struct it might break some parts of the 
program elsewhere where a function attempts to return a reference to 
something that looks like your new member.

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