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.
