An important potential change to the language: transitory ref

[Michel Fortin]

On 2010-03-20 12:41:48 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 03/20/2010 06:53 AM, Michel Fortin wrote:
>> On 2010-03-20 02:53:50 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> said:
>> 
>>> Perhaps it means you can't return ref returns from other functions if
>>> you pass them references to local state.
>> 
>> You realize you're doing that all over the place in std.range when a
>> range wraps another one?
>> 
>> struct WrapperRange(R) {
>> R wrappedRange;
>> ref ElementType!R front() {
>> return wrappedRange.front();
>> }
>> }
>> 
>> How do you plan to implement that in your proposed ref regime? Member
>> functions receive 'this' as a ref argument, so they can't return a ref
>> don't they?
> 
> Hmmm, I think returning a ref to a member should be allowed as long as 
> the compiler realizes that ref has the same scope as the struct it 
> originated from.

Ok, so the compiler assumes that the scope of the ref returned by 
function is the same as its ref arguments and prevent you from 
returning a ref to it if one of the ref argument is a local variable?

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. But there's an easy solution for 
that: add a marker. For instance: a 'ref' argument is acceptable for a 
return value, and 'scope ref' argument cannot be used as a return 
value. ('scope' here exists only as a restriction for 'ref', it is not 
applicable to anything else.)


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