DIP 36: Rvalue References

[Manu]

On 22 April 2013 03:39, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 04/21/2013 02:51 AM, Manu wrote:
>
>> On 21 April 2013 06:51, Timon Gehr <timon.gehr at gmx.ch
>> <mailto:timon.gehr at gmx.ch>> wrote:
>>
>>     On 04/20/2013 05:56 PM, Dicebot wrote:
>>
>>         You miss quite an important point - DIP36 does not add new
>>         feature. It
>>         partially defines existing feature (scope) to replace an
>>         existing but
>>         broken solution (auto ref). Nothing new is really added to the
>>         language,
>>         only existing stuff better defined.
>>
>>
>>     _New meaning_ is assigned to existing grammar whose original purpose
>>     is at most loosely related to the _new_ features.
>>
>>     I do not think that making 'scope' indicate an rvalue reference is
>>     particularly future proof.
>>
>>
>> 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?


// ???
>
> struct S{
>     scope S* x; // ???
> }
>

I don't think scope on a struct member makes a lot of sense.
scope on a local variable declaration makes sense though, it would be able
to be assigned from another scope variable.
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. 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.
This offers the possibility to pass a temp safely, and consequently, the
compiler may generate the temp for you.

Explain to me what meaning 'scope' has been assigned that is different from
it's intention? And what 'special behaviour'?

I honestly can't understand the objections, by you or deadalnix. Can
someone actually explain the problem clearly?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130422/6b4b9f46/attachment.html>