On Tuesday, 23 April 2013 at 10:07:57 UTC, Namespace wrote:
>> 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. :-)

And I initially ignored all the threads you have started until noticed proposal that looked fundamental enough in its nature. :) Features created to support one specific use case usually are not worth it. DIP36 as far as I see it is much more about scope than about rvalues.

On 04/23/2013 09:07 AM, Namespace wrote:
> 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. ...

That's fine. I don't.

On Tuesday, 23 April 2013 at 11:32:57 UTC, Timon Gehr wrote:
> On 04/23/2013 09:07 AM, Namespace wrote:
>> 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. ...
>
> That's fine. I don't.

That's fine too. :)

On 23 April 2013 21:32, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 04/23/2013 09:07 AM, Namespace wrote:
>
>> 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://forum.dlang.org/thread/4F84D6DD.5090405@digitalmars.com#post-4F84D6DD.5090405:40digitalmars.com>
>>>
>>>
>>> http://d.puremagic.com/issues/**show_bug.cgi?id=9238<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. ...
>>
>
> That's fine. I don't.
>

Can you suggest a superior/more sensible approach?
I can't see the fault in DIP36's reasoning. It just makes sense. Why is
everyone so against it? I'm yet to understand a reason...

On 4/23/13 3:07 AM, Namespace wrote:
> 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
> ----

That's on the mark. We need to make auto ref work with non-templates as well as templates, safely. The implementation mechanics may be different. Lifetime of temporaries is an important detail. I discuss such in http://d.puremagic.com/issues/show_bug.cgi?id=9238 but I never had the time to finish it.

Andrei

On 4/23/13 4:28 AM, anonymous wrote:
> 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.

Aliasing would kill that. We considered it.

Andrei

On 4/23/13 6:39 AM, Dicebot wrote:
> On Tuesday, 23 April 2013 at 10:07:57 UTC, Namespace wrote:
>>> 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. :-)
>
> And I initially ignored all the threads you have started until noticed
> proposal that looked fundamental enough in its nature. :) Features
> created to support one specific use case usually are not worth it. DIP36
> as far as I see it is much more about scope than about rvalues.

If it were about scope it would be very careful with lifetime of temporaries.

Andrei

On 4/23/13 10:05 AM, Manu wrote:
> I can't see the fault in DIP36's reasoning. It just makes sense. Why is
> everyone so against it? I'm yet to understand a reason...

1. It defines a new language feature instead of improving the existing ones. At this point in the development of the language, our preference should be putting the existing features in good order.

2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects.

3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role.

4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. In particular we are much more inclined to impart real, demonstrable safety to "ref" and to make "auto ref" work as a reference that can bind to rvalues as well as lvalues.


Andrei

On Tuesday, 23 April 2013 at 14:28:54 UTC, Andrei Alexandrescu wrote:
> If it were about scope it would be very careful with lifetime of temporaries.
>
> Andrei

Please explain. In its current form DIP36 only cares that passed temporary exists while called function is executed. I can't imagine any sane lifetime rules that would result in violating this.

On Tuesday, 23 April 2013 at 14:38:12 UTC, Dicebot wrote:
> On Tuesday, 23 April 2013 at 14:28:54 UTC, Andrei Alexandrescu wrote:
>> If it were about scope it would be very careful with lifetime of temporaries.
>>
>> Andrei
>
> Please explain. In its current form DIP36 only cares that passed temporary exists while called function is executed. I can't imagine any sane lifetime rules that would result in violating this.

This isn't enough for a DIP. You have to explicitly define the lifetime, as it is required to know what is safe and what isn't, to get deterministic destruction, or whatever.