DIP 36: Rvalue References

[kenji hara]

2013/4/10 Zach the Mystic <reachzach at gggggmail.com>

> On Tuesday, 9 April 2013 at 17:06:47 UTC, Namespace wrote:
>
>> http://wiki.dlang.org/DIP36
>>
>
> // Does not pretend to be @safe any more
> void test2(ref A a) {
> }
>
> I believe 'ref' still *can* be @safe. The unsafe action is really when you
> assign it to a global pointer.
>
> void test2(ref A a) {
>   static A* p;
>   p = &a; // <-- This is really the only unsafe thing
> }
>
> I think for convenience the function must only be considered unsafe if it
> does the above. Even returning the 'ref' is @safe so long as the *caller*
> keeps track of what it passes in, according to DIP25.
>
> "Following limitation apply to scope ref function parameters (including in
> ref):
> ...3. Parameter can only be used as an argument for other function if it
> also accepts scope ref, no implicit casting away."
>
> The DIP fails to mention that 'scope' by itself implies 'ref', and
> (presumably) can be reserved for cases where the caller specifically does
> not want to allow rvalue temps. 'scope' implies 'ref' because value types
> are inherently @safe and need no attributes. I'm not sure what's so bad
> about allowing 'scope ref' arguments to be passed to 'scope' parameters
> also. It passes the ref it receives, but since it's still 'scope', it's not
> going anywhere.
>
> Also, given that 'scope' implies 'ref', there may be significant advantage
> in simply allowing *all* scope parameters to accept rvalue temps. It would
> be helpful to have a use case where 'scope' was clearly desired but rvalue
> temps clearly *not* desired. In most cases, it seems, anything marked
> 'scope' could easily accept an rvalue temp no problem.
>
> The 'scope ref' syntax does have a slight conflict with DIP25 and my
> suggested addition DIP35, in that if other means are found to making
> returning 'ref' safe, 'scope ref' as a syntax means that no rvalue
> temporary can ever be returned. Since this may be perfectly acceptable from
> a 'bad practices' point of view, 'scope ref' may still be a good syntax.
> But if it were seen as okay to return even a an rvalue temporary, since it
> is made safe by other means, 'scope ref' would either not be usable for
> this or would actually be (confusingly) returnable.
>

I think having both 'ref' and 'scope ref' is still reasonable, because:

1. According to DIP25, escaping ref parameter is always safe. But, for
rvalue reference, it allows meaningless code.

// Even if this is allowed, it is safe. BUT will introduce bad practice.
ref int foo(scope ref int x) { return x; }

// safe
ref int bar(ref int x) { return x; }

void test() {
    int x;
    foo(x) = 10;    // may useful but...
    foo(1) = 10;    // completely useless!

    bar(x) = 10;    // may useful, and
    bar(1) = 10;    // disallowed.
}

2. Certainly 'scope' by itself _can_ imply 'ref'. BUT, currently a function
parameter without 'ref' storage class implies having value semantics (==
copy).
If we change the 'scope' meaning to 'implicit ref', it will break the
consistency.

And, 'scope' is alredy used for delegate parameter.

int opApply(scope int delegate(ref int) dg);

Such a semantic modification will silently change the meaning of existing
code. It's not good to me.

Kenji Hara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130410/7ad51fd1/attachment.html>