On Tuesday, 2 June 2015 at 21:20:49 UTC, Andrei Alexandrescu wrote:
> Yah, auto ref for templates is great. We only need to add auto ref for non-templates with the semantics "like ref, except (a) accepts rvalues on the caller side, (b) does not allow escaping the ref from the function".
That would work once DIP 25 is fully implemented and if auto ref for non-templates would not include return ref. Or am I missing something?

> Note that __traits(isRef, param) doesn't work in an auto ref param in a non-template function (attempt to use must be a compile-time error).
>
> That's about it.
>
>
> Andrei

On 6/2/15 2:28 PM, Namespace wrote:
> On Tuesday, 2 June 2015 at 21:20:49 UTC, Andrei Alexandrescu wrote:
>> Yah, auto ref for templates is great. We only need to add auto ref for
>> non-templates with the semantics "like ref, except (a) accepts rvalues
>> on the caller side, (b) does not allow escaping the ref from the
>> function".
> That would work once DIP 25 is fully implemented and if auto ref for
> non-templates would not include return ref. Or am I missing something?

Sounds about right. -- Andrei

On 3 June 2015 at 07:21, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 6/2/15 11:19 AM, Jonathan M Davis wrote:
>>
>> On Tuesday, 2 June 2015 at 18:05:20 UTC, Namespace wrote:
>>>
>>> AFAIK Andrei wanted 'auto ref' as the syntax which accepts both,
>>> lvalues and rvalues. That's why I'm asking if the current behaviour
>>> for auto ref for templates should change, or not. If not, we have (as
>>> you said) two meanings of auto ref, what is not optimal, but not so
>>> bad either (IMO).
>>> But if I had the choice, I would change it for both, so that both
>>> create a temporary variable for rvalues.
>>
>>
>> Andrei originally wanted auto ref to apply to non-templated functions, but Walter misunderstood what he meant and created what we have now - which is actually incredibly useful, because it allows you to forward the attributes of an argument - in particular, it's ref-ness. So, we definitely do _not_ want to lose that.
>
>
> Yah, auto ref for templates is great. We only need to add auto ref for non-templates with the semantics "like ref, except (a) accepts rvalues on the caller side, (b) does not allow escaping the ref from the function".
>
> Note that __traits(isRef, param) doesn't work in an auto ref param in a
> non-template function (attempt to use must be a compile-time error).
>
> That's about it.


You're killing me! I thought 'scope ref' was more-or-less agreed? auto ref makes no sense.

On Tue, 02 Jun 2015 14:06:31 -0400, Namespace <rswhite4@gmail.com> wrote:

> On Tuesday, 2 June 2015 at 17:22:07 UTC, Marc Schütz wrote:
>> On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
>>> Thanks to DIP 25 I think it's time to review this again. I would implement it (if no one else wants to do it), but there are still some unanswered questions:
>>>
>>> 1. Is 'auto ref' still the chosen syntax (I guess so)?
>>
>> Why not `scope ref` (or `in ref` == `const scope ref`)?
>
> See DIP 36
>

I'm feeling like a bit of a troll here, but I can't help myself.

'in' is currently useless because scope is not defined properly, and const is too restrictive. Also, because of DIP25, it's now even more useless. It seems a pretty sure bet that it will either continue to be completely useless or be changed at some point anyways, so why not now? If it's only been around since 2.060, how bad could the code breakage really be? Replace All a few times and you're done. A compiler warning could be issued for the next few versions to notify users that the meaning of 'in' has changed, if needed.

So why not re-brand this awesomely concise and convenient keyword to be the "non-template auto ref"?

  Bit

On Wednesday, 3 June 2015 at 01:57:21 UTC, bitwise wrote:
> On Tue, 02 Jun 2015 14:06:31 -0400, Namespace <rswhite4@gmail.com> wrote:
>
>> On Tuesday, 2 June 2015 at 17:22:07 UTC, Marc Schütz wrote:
>>> On Tuesday, 2 June 2015 at 16:02:56 UTC, Namespace wrote:
>>>> Thanks to DIP 25 I think it's time to review this again. I would implement it (if no one else wants to do it), but there are still some unanswered questions:
>>>>
>>>> 1. Is 'auto ref' still the chosen syntax (I guess so)?
>>>
>>> Why not `scope ref` (or `in ref` == `const scope ref`)?
>>
>> See DIP 36
>>
>
> I'm feeling like a bit of a troll here, but I can't help myself.
>
> 'in' is currently useless because scope is not defined properly, and const is too restrictive. Also, because of DIP25, it's now even more useless. It seems a pretty sure bet that it will either continue to be completely useless or be changed at some point anyways, so why not now? If it's only been around since 2.060, how bad could the code breakage really be? Replace All a few times and you're done. A compiler warning could be issued for the next few versions to notify users that the meaning of 'in' has changed, if needed.
>
> So why not re-brand this awesomely concise and convenient keyword to be the "non-template auto ref"?

Where on earth did you get the idea that in was introduced in 2.060? in existed in D1. Its meaning was slightly different then, but it was kept in D2 and its meaning changed in a manner that was intended to be reasonably compatible with D1 code. And folks _love_ using in, because they view it as the opposite of out. Almost always, it's really just const, since scope really only applies to delegates at this point, but in is used _heavily_ by many folks in the D community.

I keep telling folks not to use in, because scope isn't well-defined yet, so who knows what's going to happen when we _do_ try and define it properly, but folks keep using it anyway. We can't just change the meaning and expect it not to break code. That's part of what's going to be so ugly about finishing scope. And there are folks who use in fully understanding the risks under the assumption that scope will be defined in a way that does what they want. So, many folks are relying on in being equivalent to const scope, and changing it to mean something else is just plain a bad idea.

- Jonathan M Davis

On Tue, 02 Jun 2015 22:28:48 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> Where on earth did you get the idea that in was introduced in 2.060?

DIP36:
"in ref has been allowed from 2.060 : http://d.puremagic.com/issues/show_bug.cgi?id=8105"

Reading it more carefully this time, I understand what it's saying now =(

> And folks _love_ using in, because they view it as the opposite of out.

To be symmetrical with 'out' shouldn't 'in' == 'const scope ref'?

> Almost always, it's really just const, since scope really only applies
> to delegates at this point, but in is used _heavily_ by many folks in
> the D community.

I still think that it could be put to better use than an alias for const.

> I keep telling folks not to use in, because scope isn't well-defined yet, so who knows what's going to happen when we _do_ try and define it properly, but folks keep using it anyway.

Exactly my point, because it's awesomely convenient, which is why it should
have a more useful meaning :)

> We can't just change the meaning and expect it not to break code. That's
> part of what's going to be so ugly about finishing scope. And there are
> folks who use in fully understanding the risks under the assumption that
> scope will be defined in a way that does what they want. So, many folks
> are relying on in being equivalent to const scope, and changing it to
> mean something else is just plain a bad idea.

I have seen a lot of posts on these forums about people being tired of
breaking changes in D, and I understand that, but I believe 'in' should be
an exception. It's kind of a 'beta' feature, and people should expect that
it's subject to change, especially considering that googling 'dlang in ref'
yields your warning as the second result :)

"1. Don't use in."

Anyways, moving forward with the assumption that the meaning of 'in' will
not change, I still don't understand. Why couldn't 'in ref' be allowed to
accept rvalues in addition to 'auto ref'?

  Bit

On Wednesday, 3 June 2015 at 03:20:48 UTC, bitwise wrote:
> Anyways, moving forward with the assumption that the meaning of 'in' will
> not change, I still don't understand. Why couldn't 'in ref' be allowed to
> accept rvalues in addition to 'auto ref'?

For the same reasons that we can't have const ref accept rvalues, especially since in ref basically _is_ const ref in most cases right now.

- Jonathan M Davis

On Tue, 02 Jun 2015 23:23:00 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Wednesday, 3 June 2015 at 03:20:48 UTC, bitwise wrote:
>> Anyways, moving forward with the assumption that the meaning of 'in' will
>> not change, I still don't understand. Why couldn't 'in ref' be allowed to
>> accept rvalues in addition to 'auto ref'?
>
> For the same reasons that we can't have const ref accept rvalues, especially since in ref basically _is_ const ref in most cases right now.
>
> - Jonathan M Davis

Why can't const ref accept rvalues?

const being too restrictive doesn't seem like a real reason, because
although its undesirable for some cases, doesn't mean it can't be useful
in a _lot_ of other cases.

Also, with DIP25, isn't 'const ref' the same thing that 'const scope ref' was
supposed to be anyways?

I can't remember right now what the reasoning was for 'const ref' not to take
rvalues in the first place. I think it was that you could escape the reference,
but this isn't true anymore with DIP25 right?

  Bit

I forgot to mention, in terms of this statement I made:

> I can't remember right now what the reasoning was for 'const ref' not to take
> rvalues in the first place. I think it was that you could escape the reference,
> but this isn't true anymore with DIP25 right?

I think someone brought this up about a weeks ago, and this
was Andrei's response:

> Knee-jerk response: if no "return" attribute on a function it should be safeto bind rvalues to ref parameters. Of course that's impractical as a default
> so explicit "auto ref" would be needed. -- Andrei

What's impractical?

  Bit

On Wednesday, 3 June 2015 at 03:43:09 UTC, bitwise wrote:
> I can't remember right now what the reasoning was for 'const ref' not to take
> rvalues in the first place. I think it was that you could escape the reference,
> but this isn't true anymore with DIP25 right?

The one to ask is Andrei. I can never remember all of the details, because it has to do with the details of how it causes problems in C++. IIRC, the problem stems from the fact that you can no longer tell whether the parameter represents an lvalue or a temporary. I don't know how big a deal it really is, but Andrei is emphatic about it.

But regardless, because of how restrictive const is in D, requiring const to have a parameter accept both lvalues and rvalues is just too restrictive anyway. A lot of the same developers who are insistent on having rvalue references for efficiency are exactly the sort of developers who will avoid const, because it's physical const and not logical const and thus prevents stuff like caching or lazy loading.

- Jonathan M Davis