DIP 36: Rvalue References

[Manu]

On 10 April 2013 12:40, kenji hara <k.hara.pg at gmail.com> wrote:

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

Why are you suggesting changing scope to imply ref? This seems wrong. scope
and ref are separate, should remain that way.
Arguments would be scope ref, or in ref, thus allowing rvalues. Without
ref, I would imagine that the meaning is such that, even though the
argument is a copy, it, or members thereof are not allowed to escape.

struct X { int *p; }
int* global;

void func(scope X x) // note: is not ref
{
  global = x.p; // <- error! scope prevents any part of x escaping, even
though it's a copy.
}

This way, scope has meaning with or without ref.


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

What does scope mean in this case? Is this a conflict in some way?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130410/f9472cf9/attachment.html>