rvalue references

[Zach the Mystic]

On Saturday, 27 April 2013 at 23:38:53 UTC, Diggory wrote:
> The keyword 'scope' is very well defined at the moment - it 
> means among other things that the value cannot be returned.

It's only defined very briefly in the "functions" section of the  
documentation. And it's only implemented for 'scope' delegates, 
because they get a clear benefit. Making 'ref' safe, despite how 
important it is, is not yet encoded in stone. DIP25A has been 
admitted by its author to be an aggressive solution. But there 
are several possible approaches to dealing with that, IMO. The 
most immediate is to simply force the author to mark any function 
which violates the rules '@trusted'. In other words, sweep all 
unsafe cases under the umbrella of the existing @safe-D 
framework. Perhaps the only reason to consider anything else is 
that the number of functions which will have to be marked 
'@trusted' will be too high.

I think it's important to decide whether '@trusted' is adequate 
to address 'ref' safety before getting to the next step. I even 
think that a full implementation of DIP25A, as is, would help to 
determine for people just how many functions they will be forced 
to mark '@trusted'. Only if '@trusted' really ends up being too 
blunt should attributes be considered, IMO.

That being said, 'scope' might be the right tool for the job. Or 
'out' return values. I'm not under the impression that 'scope' 
*must* be used to solve the problem. For example, there are even 
more than one way to escape a parameter, and they're not all 
equal.

ref T func(ref T a, ref T* b) {
   return a; // Escape by return
   static T* t;
   t = &a; // Escape by global assign
   b = &a; // Escape by parameter assign
}

'scope' is only one attribute, yet there are three different 
types of escape here. That's why I don't want to jump in 
completely on 'scope' banning all three.