DIP 36: Rvalue References

[Timon Gehr]

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++.