DIP 36: Rvalue References

Zach the Mystic reachzach at gggggmail.com
Sun Apr 21 16:34:38 PDT 2013


On Sunday, 21 April 2013 at 22:16:14 UTC, Timon Gehr wrote:
> What does 'scope' bind to? How to make it bind to something 
> else (if at all)?

I agree this is an issue. We need to enumerate the use cases. Is 
'scope' transitive or does it only apply to the first thing it 
hits?

>> Passing an r-value by ref is disallowed for arbitrary reasons.
>
> Reasons not closely related to lack of 'scope'. So why bind the 
> new rule to scope?

I think that it's possible to consider binding it as a convenient 
benefit of what 'scope' is generally meant to do anyway. I think 
the crossover of the two features is quite high. But it is a 
judgment call. Sometimes you may want to allow rvalue refs 
without prohibiting escaping them, or prohibit escaping them 
without allowing rvalues refs. But the point of 'scope' is that 
it safely takes stack references, which is exactly what rvalue 
temps are.

Maybe getting the two features separate is good, but since it 
will require another parameter attribute, it suggests a need for 
increased reliance on attribute inference to spare the programmer 
the trouble. The main reason to consider combining is that it 
saves on syntax.

> If I read the ambiguous wording of the proposal correctly, the 
> following code will be disallowed:
>
> void foo1(scope ref int x) { }
>
> void main(){
>     foo1(1); // error
> }

My impression is that this would be allowed, not disallowed.

> But this will be fine:
>
> void foo1(scope ref int x) { }
> int bar(){ return 1; }
>
> void main(){
>     foo1(bar());
> }

I think this would also be allowed.


More information about the Digitalmars-d mailing list