My thoughts & tries with rvalue references

[Namespace]

> 'scope ref': The only existing documentation on scope 
> parameters: http://dlang.org/function.html suggests that 
> references to them simply cannot leave the function they find 
> themselves in. But this is *not* what the temp ref feature is 
> about. Say you have this temp ref function:
>
> ref int func(@temp ref int a) { return a; }
>
> According to the spec, it clearly violates 'scope', but is 
> nonetheless valid and safe, as far as I can tell. The compiler 
> can easily track the scope of a given lvalue at the call site:
>
> static int* x;
> static int y;
> x = *func(3); // Error: result of func(3) is assumed to be local
> x = *func(y); // Pass: address of y is known to be global
>
> This kind of safety checking is not yet implemented, but is 
> suggested in DIP25, http://wiki.dlang.org/DIP25 . I believe it 
> is the right way to go. The locality of the return by reference 
> is assumed to be as local as the reference which is passed into 
> it. So the temp '3' reference would make the result of func(3) 
> yield a local, barring any other information which would allow 
> the compiler to safely assume otherwise. In essence, '@temp 
> ref' can escape its scope safely because the locality of the 
> result is not its responsibility.
As far as I know Andrei works on DIP25 and as far as I know from 
his thread in D.bugs he has already began with the implementation.
But I agree with you that 'scope ref' should be smart enough to 
detect case #2 and allow it.

> '@ref': I like this less than 'ref&' because it is even less 
> clear what it means than 'ref&' is. The two problems with 
> 'ref&', so far as I understand it, are 1, that it looks like a 
> one-character hack which generally not well-liked in this 
> community, and 2, it could be confused with a double-reference. 
> I personally don't think I'm going to confuse 'ref&' with 'ref 
> *'. At least 'ref&' gives a hint that it has something to do 
> with taking the address of something. '@ref' is nothing more 
> than saying, "Hey, I can take '@' and put it before keyword 
> 'ref'. Look at me!". I'm not for it at all.
:D
Yes, there already is some truth to it.

> If 'ref&' or '@ref' are rejected on the basis of their being 
> one-character hacks, then the search is on for a good '@' word 
> or an existing keyword which does the trick. I wish 'scope' 
> could cover it, but I personally don't see how that keyword as 
> defined covers this feature as proposed.
I think with Andreis improvements on the current ref 
implementation, scope ref could do the job. It must only be smart 
enough to detect such cases as you described above.

> I looked for other existing keywords to do the job, but I 
> didn't find one which met my personal sense of what would work. 
> 'auto ref' would have been a perfect name for it if 'auto ref' 
> hadn't already found great use in templates. All I have, 
> therefore, are '@val' and, given this post, '@temp':
>
> void func(@val ref int a) {}
> void func(@temp ref int a) {}
>
> I think '@val' is pretty good. I don't think this feature 
> merits its own keyword, so the '@' is there to stay, but at 
> least '@val' is only four letters long, exactly the same number 
> of characters as 'auto'.
>
> Does anyone else have a better '@ttribute' for this feature, 
> assuming one-char hacks are out of the question?

I don't like @val because I don't see the coherence between 
rvalue references and value references. Or I don't understand it 
right now. But @temp would be a good alternative if some others 
with more knowledge than me think also, that scope ref isn't the 
right way to go and @ref/ref& are dirty hacks.