My thoughts & tries with rvalue references

[Zach the Mystic]

On Tuesday, 2 April 2013 at 15:08:20 UTC, Namespace wrote:
> On Saturday, 30 March 2013 at 12:00:32 UTC, Namespace wrote:
>> As far as I studied the code, something like @ref isn't 
>> possible, because ref is already a keyword. Except as 
>> Pseudo-property. But this is a combination of '@' and 'ref' so 
>> that both, '@ref' and '@ ref' would be valid.
>> I still like the idea of '&A'.
>
> I have to disagree with me here.
> Thanks to this thread 
> (http://forum.dlang.org/thread/ohjdraaizvwiczifwrlk@forum.dlang.org) 
> I know now that after the '@' can be an unlimited number of 
> white spaces.
> Hence my previous speculation that I would have implemented 
> something wrong is wrong. So is something like '@ref' possible 
> and already implemented, as you can see here: 
> https://github.com/Dgame/dmd/tree/rvalue_property
>
> I think this is probably the end result of my little journey. 
> Any objections?

'@ref' is actually my least favorite choice. Of all presented, my 
two favorites are

void func(ref& int a) {}

void func(@val ref int a) {}

Hara Kenji's comment about 'scope ref' also raises the issue of 
just how subtle is the difference between this proposed feature 
and what 'auto ref' does in templates. Correct me if I'm wrong, 
but 'ref&' is proposed to have the compiler create a temporary at 
the call site and pass it as a reference.

ref int func1(ref& int a) { return a; }

// Example:

int func2(ref int b) { return a; }
int x = func2(func1(3));

The above passes because the temporary ref to "3" created for 
func1 survives the whole expression, I believe. func1 returns the 
3 as a ref, which ref should not escape the original expression, 
but may escape func1 itself. So 'scope ref' cannot be used. 
'scope ref' *could* be used for the related "performance ref" 
issue, wherein the compiler decides whether a ref or value is 
appropriate knowing full well there's no chance of escaping.

There are actually three ref issues here. The performance ref 
issue is related to the compiler making automatic choices which 
have no affect on semantics. The other two issues are related to 
the Don't Repeat Yourself problem. 'auto ref' is the template 
solution which actually creates new functions depending on what 
is passed to it. The alternative solution is what's being 
proposed here, which I'll call the 'temp ref' solution. Instead 
of passing values to a custom created function, all rvalues are 
simply converted to temporary lvalues at the call site, with the 
caller responsible for tracking the value's scope.

It might seem convenient to use the syntax 'auto ref' to tell a 
non-templated function to do this, but that syntax has been 
rejected for reasons I either never understood well enough or 
I've simply forgotten.

All-in-all, the syntax 'ref &' seems harmless enough to me. As 
far as getting it to work with templates, the feature is clearly 
mutually exclusive with 'auto ref', but I'm not sure why any 
other usage would be a problem.