rvalue references

[Zach the Mystic]

On Sunday, 28 April 2013 at 16:56:26 UTC, Diggory wrote:
> It's quite clear to me that no mathematical model for ref 
> safety will be able to cover every possible case without 
> seriously degrading performance. Therefore the best we can do 
> is come up with a model which covers as many of the common 
> situations as possible and rely on "@trusted" to handle the 
> (hopefully small) number of cases which cannot be handled by 
> the model.

This is my thinking also.

One rather bad thing about the '@trusted' method is that it's not 
the called function itself which is unsafe, but only escaping the 
*returned ref*, and so '@trusted' would most accurately have to 
attach to the *calling* function, which I think will become 
untenable rather quickly.

ref T func(ref T a); // Safe in and of itself

@trusted ref T fun2() {
   T b, c;
   b = func(c); // safe
   return func(c); // not safe!!
}

Since func() has no additional attributes and is invisible, 
there's no way at all for the compiler to know what it returns. 
Yet the actual unsafe action only occurs in fun2(), which makes 
it easy to see how unwieldy the system could get, having to mark 
the calling function just because it does something which *could* 
be unsafe.

Looking at the above case makes it seem like at least one 
additional attribute, located in the function signature, must be 
accessible to the compiler in to order to reduce the number of 
functions which must otherwise rather gratuitously be marked 
'@trusted'. Even with a single new attribute, 'out', which 
attaches to the function (and does not specify precisely to which 
parameters it refers) I suspect a huge number of frustrating 
cases would be taken care of. 'out', of course, simply assigns 
'@noreturn' to all its parameters, even if '@noreturn' itself is 
not allowed!