rvalue references

[Diggory]

On Sunday, 28 April 2013 at 05:19:50 UTC, Zach the Mystic wrote:
> 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.

OK, but I think it should be made clear that using scope for 
rvalue references would change the meaning of an attribute that 
in the near future will be very useful indeed as-is, and we will 
probably end up wanting to make a new attribute "@noreturn" or 
something if scope now means something else (TBH I would not 
really be against using "@noreturn" as it's somewhat clearer than 
"scope" but swapping one attribute for another seems like 
something people would be against?)

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.

So far the rules in DIP25A+DIP35 seem to get the closest to this 
ideal model, and there's no reason we can't extend the rules even 
further to cover even more cases in the future.