Previous discussions:

http://forum.dlang.org/thread/4F84D6DD.5090405@digitalmars.com#post-4F84D6DD.5090405:40digitalmars.com

http://d.puremagic.com/issues/show_bug.cgi?id=9238

On Tuesday, 23 April 2013 at 03:30:35 UTC, Walter Bright wrote:
> Previous discussions:
>
> http://forum.dlang.org/thread/4F84D6DD.5090405@digitalmars.com#post-4F84D6DD.5090405:40digitalmars.com
>
> http://d.puremagic.com/issues/show_bug.cgi?id=9238

I still like the Idea of DIP 36 (http://wiki.dlang.org/DIP36) with scope ref / in ref. On this link we have also collected several other suggested syntaxes.
But maybe we should discuss first, if auto ref could work for non-templates.
This would mean that
1. auto ref generate code bloat for non-templates (doubled the function 2^n times)
or
2. auto ref works like scope ref would do (create a temporary lvalue and pass this to the function). But that would mean that auto ref work differently for templates and non-templates (maybe a problem?). If we choose this we should also discuss about the lifetime of the temporary:
----
foo(auto ref A a) { }

foo(A());
// should then converted to
{
    A __temp = A();
    foo(__temp); // after this, __temp is destroyed
}
----
or
3. the compiler choose if an argument should be passed by ref, by value or should be moved.
For example:
----
A a = A(42);
foo(a); // by ref
foo(A(23)); // move
----

I'd still like someone to explain how exactly "scope ref" would differ from "ref" if DIP25/DIP35 were implemented.

If the only difference is that "scope ref" can accept rvalues then why would you ever use normal "ref"? There are no extra restrictions needed on "scope ref" over and above normal "ref" under the assumption of DIP25/DIP35.

On Tuesday, 23 April 2013 at 07:18:41 UTC, Diggory wrote:
> I'd still like someone to explain how exactly "scope ref" would differ from "ref" if DIP25/DIP35 were implemented.
>
> If the only difference is that "scope ref" can accept rvalues then why would you ever use normal "ref"? There are no extra restrictions needed on "scope ref" over and above normal "ref" under the assumption of DIP25/DIP35.

No it is not the only difference. "scope ref" (as proposed in DIP35) is more restrictive in usage - can't take address of it, can't return it, can't implicitly cast it to normal ref. It is "scope" primarily and "rvalue ref solution" only secondarily.

On Tuesday, 23 April 2013 at 07:45:41 UTC, Dicebot wrote:
> ...

Ah, beg my pardon, I though it is yet another misunderstanding about DIP36.

On Tuesday, 23 April 2013 at 03:30:35 UTC, Walter Bright wrote:
> Previous discussions:
>
> http://forum.dlang.org/thread/4F84D6DD.5090405@digitalmars.com#post-4F84D6DD.5090405:40digitalmars.com
>
> http://d.puremagic.com/issues/show_bug.cgi?id=9238

As far as I understand the "usability disaster" of disallowing rvalue references is that I have to define a non-ref overload forwarding to my function(ref arg).
That ref can't be for functionality, because I'm expecting references to rvalues/temporaries. => ref is merely for performance, and the parameter can be const.

Now, this may be too naive, but what about allowing the compiler to pass regular (not declared ref) const arguments per reference as it sees fit? It would be just another optimization.

I'd declare function(const arg) and that would be it.

On Tuesday, 23 April 2013 at 07:18:41 UTC, Diggory wrote:
> I'd still like someone to explain how exactly "scope ref" would differ from "ref" if DIP25/DIP35 were implemented.
>
> If the only difference is that "scope ref" can accept rvalues then why would you ever use normal "ref"? There are no extra restrictions needed on "scope ref" over and above normal "ref" under the assumption of DIP25/DIP35.

DIP25 imposes a number of code-breaking restrictions even in @system code, if DIP36 was in place, one could consider imposing the DIP25 restrictions only in SafeD.

Furthermore if one day the compiler would be sufficiently smart to infer scope automatically, there still would be an important difference between 'ref' and 'scope ref'.

ref
rvalue ref would only work if the compiler succeeds in inferring scope, it could take a conservative approach to make sure it always err:s in the harmless direction... i.e. any '&' or any asm block is an automatic failure.

scope ref
Works unless the compiler can prove it wrong(also usable from SafeD if marked with @trusted).

On Tuesday, 23 April 2013 at 08:41:16 UTC, Tove wrote:
> DIP25 imposes a number of code-breaking restrictions even in @system code, if DIP36 was in place, one could consider imposing the DIP25 restrictions only in SafeD.
>
> Furthermore if one day the compiler would be sufficiently smart to infer scope automatically, there still would be an important difference between 'ref' and 'scope ref'.
>

That is the important issue to solve. Many solution can jeopardize DIP36, which is why it must be delayed.

Usually conflating issue in adhoc solution ends up in crap that must be sorted out later.

On Tuesday, 23 April 2013 at 09:06:52 UTC, deadalnix wrote:
> On Tuesday, 23 April 2013 at 08:41:16 UTC, Tove wrote:
>> DIP25 imposes a number of code-breaking restrictions even in @system code, if DIP36 was in place, one could consider imposing the DIP25 restrictions only in SafeD.
>>
>> Furthermore if one day the compiler would be sufficiently smart to infer scope automatically, there still would be an important difference between 'ref' and 'scope ref'.
>>
>
> That is the important issue to solve. Many solution can jeopardize DIP36, which is why it must be delayed.
>
> Usually conflating issue in adhoc solution ends up in crap that must be sorted out later.

I see it as a future proof feature, not an issue. You want it to be a difference, so you can override the default compiler behavior.

> No it is not the only difference. "scope ref" (as proposed in DIP35) is more restrictive in usage - can't take address of it, can't return it, can't implicitly cast it to normal ref. It is "scope" primarily and "rvalue ref solution" only secondarily.

My initial reason was to solve the rvalue ref issue. So it is completly inverse for me. :-)