On 04/21/2013 10:38 PM, Manu wrote:
...
That's not what scope does. Scope promises that the variables
will not
escape the scope.
That is the intention, but this formulation is awfully imprecise.
Hence nothing has been implemented.
void foo(scope ref int x){ ... }
void foo(scope int* x){ ... }
void foo(scope ref int* x){ ... }
What's the problem here?
What does 'scope' bind to? How to make it bind to something else (if at
all)?
Does the proposal lock down 'scope' to always refer to every single
pointer in the argument?
// ???
struct S{
scope S* x; // ???
}
I don't think scope on a struct member makes a lot of sense.
void main()@safe{
S s;
auto t = S(&t);
}
scope on a local variable declaration makes sense though, it would be
able to be assigned from another scope variable.
'scope' shouldn't restrict the abstraction capability of structs.
Although I would say the same about ref on a local variable declaration,
which is disallowed for completely unknown reasons.
And as such, just happens to make passing a temporary
by ref safe.
...
But this is not about safety! Passing an rvalue by ref is disallowed
even in @system code. Hence 'scope' is assigned a meaning different
from its intention. The DIP also aims to add more special behaviour
to built-in literals.
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?
It can easily create a temporary on the spot, but it doesn't, because it's not
considered good form to pass a temp to a function by ref. ...
Yet this is what everyone appears to want to do.
Explain to me what meaning 'scope' has been assigned that is different
from it's intention?
Implicit binding of (some) rvalues to ref.
And what 'special behaviour'?
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
}
But this will be fine:
void foo1(scope ref int x) { }
int bar(){ return 1; }
void main(){
foo1(bar());
}
I honestly can't understand the objections, by you or deadalnix. Can
someone actually explain the problem clearly?
Having a lot of ad-hoc programming language rules leads to a clumsy
design. Eg. see the evolution of C++.
