DIP 36: Rvalue References

[Zach the Mystic]

On Wednesday, 10 April 2013 at 02:41:10 UTC, kenji hara wrote:
> 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.
> }

'foo(1) = 10' is indeed completely useless, but I don't think all 
uses are completely useless. But I will concede that allowing 
things like 'foo(1)' may be useless *enough* to disallow it 
without anyone feeling bad. I have made DIP35, 
http://wiki.dlang.org/DIP35 , which utilizes 'scope' to actually 
make DIP25 more flexible, which I think is probably good. The 
example I used was the 'copy' function. 'foo' above, rewritten as 
the copy function would be:

ref int foo(scope ref int x) {
   int* y = new int;
   *y = x;
   return y;
}

DIP25 may *need* to use 'scope' in this way to know that foo() 
will always give a fresh value - so it can treat it like a global 
safely. Thus 'foo(1)' will return a fresh heap allocated copy of 
"1".

ref int test() {
   return foo(1); // allowed
   return bar(1); // disallowed!
}

Without the 'scope' parameter, there would be no way the compiler 
could know. Therefore, it is not completely useless.

> 2. Certainly 'scope' by itself _can_ imply 'ref'. BUT,  
> currently a function
> parameter without 'ref' storage class implies having value 
> semantics (== copy).

This is slightly wrong, I suspect. 'out' parameters are 
implicitly references.

> If we change the 'scope' meaning to 'implicit ref', it will 
> break the
> consistency.
>
> And, 'scope' is already 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.

Generally, I agree. My argument is for a small convenience of not 
having to type 'ref' when not necessary. It would mean that when 
the type was implicitly a reference, such as a delegate or 
object, 'ref' was *not* implied, whereas it *was* implied with a 
value type. This may or may not wreak havoc on the generic type 
system. I thought there might be an off-chance that it would 
actually be a *convenience* for the type system, since it would 
get the right level of referencing for the type involved.

I believe that the 'scope' keyword may be a necessary addition to 
DIP25 to make 'ref' fully safe and flexible (DIP35). If so, then 
there may be a conflict with using it only to mean rvalue 
temporaries. They are two separate features. I believe that if 
they are to be used together, it will be because it was decided 
that whenever you want to stop a reference from escaping, you 
*always* want to allow rvalue temporaries, and whenever you want 
to allow rvalue temporaries, you *never* want them to be 
returned. Right now, returning an rvalue temporary might seem 
dangerous, but sealed references *are* part of the plan for D, 
and there may be no need to see them as dangerous.