On 10/22/2012 11:38 AM, Timon Gehr wrote:
> On 10/22/2012 12:18 AM, martin wrote:
>> On Friday, 19 October 2012 at 00:03:49 UTC, Timon Gehr wrote:
>>> Const is different in D and in C++. Relating const and rvalues is
>>> arbitrary and does not make a lot of sense.
>>
>> It's actually pretty much the same concept in both languages except for
>> the transitiveness in D.
>
> Case closed.
>

(But it might be added that C++11 adds a new language feature just in order to be able to distinguish const and rvalue references in the
callee, so even with C++'s semantics, this does not seem like a good
idea.)

On Monday, 22 October 2012 at 09:41:38 UTC, Timon Gehr wrote:
> (But it might be added that C++11 adds a new language feature
> just in order to be able to distinguish const and rvalue
> references in the callee, so even with C++'s semantics, this
> does not seem like a good idea.)

Yeah, and that T&& syntax is mainly used for _mutable_ rvalue references in move constructors and assignment operators to move (hijack) mutable data from the rvalue to another T instance instead of copying that data, knowing that the rvalue's data is not going to be accessed anymore anyway. So this is a different case and does currently not apply to D afaik since there is no way to forward rvalues:

void foo(ref T lvalue) { }
void foo(T rvalue)     { }

In the latter overload for rvalues, you aren't given the original rvalue, but a copy of it!

Distinguishing between _const_ rvalue and lvalue references though makes no sense imho, and that is my whole point.

On Monday, 22 October 2012 at 11:59:27 UTC, martin wrote:
> In the latter overload for rvalues, you aren't given the original rvalue, but a copy of it!

I need to correct that after a quick test: the rvalue is passed directly (moved) instead of copying it (well, at least the copy constructor this(this) is not invoked, even in a debug build); that makes perfect sense, is efficient and eliminates the need for C++ rvalue references (T&&).
It doesn't affect the need for an implicit rvalue => const ref propagation though.

What I'd like to see is the following passing scheme for function arguments (read-only parameters are denoted by (*)):

              lvalue:       rvalue:
           T: copy          move
(*)     in T: copy          move
       out T: pass pointer  n/a
       ref T: pass pointer  n/a
(*) in ref T: pass pointer  store on the caller's stack and pass its address

So only the rvalue passing rule for the "in ref T" case would need to be implemented. This would allow to use "foo(in ref T bar)" for lvalues (eliding a copy expected to be costly) as well as rvalues instead of having to add an overload "foo(in T bar)" for rvalues. For rvalues, this would actually implicate a performance hit due to pointer indirection, so the compiler could attempt to add an automatic "foo(in T bar)" overload if not existent. For rvalues, the latter overload (i.e., "in T" parameters) should be preferred over "in ref T" parameters - exactly as the thread starter Malte proposes:

> - Make functions that take "ref in" arguments also accept rvalues.
> - The user can still provide an overload that accepts an rvalue, using the "in" keyword, and that one will be preferred over the "ref in" version.

On Thursday, 18 October 2012 at 03:07:56 UTC, Malte Skarupke wrote:
> Hello,
>
> I realize that this has been discussed before, but so far there is no solution and this really needs to be a high priority:
>
> We need a way for a function to declare that it doesn't want it's argument to be copied, but it also doesn't care whether the argument is an rvalue or an lvalue.
>

I'm encountering this problem right now, and found this thread while looking for a solution. In my case I'm forced into doubling up some code, which is not what I want to be doing, so I agree this item should be fixed. It would be nice to have something like the proposed "auto ref" solution, like we have with return values.

--rt

I find it sad that while this topic seems to be of high priority for quite a lot of language users, it is seemingly neglected by the head of language development (Walter, Andrei etc.).

On Monday, 5 November 2012 at 00:58:19 UTC, martin wrote:
> I find it sad that while this topic seems to be of high priority for quite a lot of language users, it is seemingly neglected by the head of language development (Walter, Andrei etc.).

I don't know why this would be ignored, it's rather useful and solves a real-world programming problem. I hope this is just one of those detials that was missed and is only being ignored due to attention from much bigger problems.

Do you know if there is already a feature request or bug report on this item?

On 11/4/12 7:58 PM, martin wrote:
> I find it sad that while this topic seems to be of high priority for
> quite a lot of language users, it is seemingly neglected by the head of
> language development (Walter, Andrei etc.).

I was hoping "auto ref" solves this problem. I think it's currently only implemented for templates.

Andrei

On Sunday, November 04, 2012 20:43:36 Andrei Alexandrescu wrote:
> On 11/4/12 7:58 PM, martin wrote:
> > I find it sad that while this topic seems to be of high priority for quite a lot of language users, it is seemingly neglected by the head of language development (Walter, Andrei etc.).
> 
> I was hoping "auto ref" solves this problem. I think it's currently only implemented for templates.

And when we argued for altering it so that it operated like const ref in C++ (which allows const ref in D to continue to function like it does now), some folks complained, because they've found the current semantics of auto ref to be useful (something to do with propagating the exact, original type, I think).

Now, since auto ref currently only works with templates, maybe we can keep its current semantics with templated functions but alter them for non-templated functions so that it works like const ref does in C++. The downside is that the semantics for auto ref between templated functions and non-templated functions are slightly different, but they're close enough that I'm not sure that it matters.

- Jonathan M Davis

On Monday, 5 November 2012 at 03:26:10 UTC, Jonathan M Davis wrote:
> On Sunday, November 04, 2012 20:43:36 Andrei Alexandrescu wrote:
>> On 11/4/12 7:58 PM, martin wrote:
>> > I find it sad that while this topic seems to be of high priority for
>> > quite a lot of language users, it is seemingly neglected by the head of
>> > language development (Walter, Andrei etc.).
>> 
>> I was hoping "auto ref" solves this problem. I think it's currently only
>> implemented for templates.
>
> And when we argued for altering it so that it operated like const ref in C++
> (which allows const ref in D to continue to function like it does now), some
> folks complained, because they've found the current semantics of auto ref to
> be useful (something to do with propagating the exact, original type, I
> think).
>
> Now, since auto ref currently only works with templates, maybe we can keep its
> current semantics with templated functions but alter them for non-templated
> functions so that it works like const ref does in C++. The downside is that
> the semantics for auto ref between templated functions and non-templated
> functions are slightly different, but they're close enough that I'm not sure
> that it matters.
>
> - Jonathan M Davis

Yes, please. Auto ref for non-template functions would solve the problem exactly. I also like it because then the intent of the programmer is clear.

On Monday, 5 November 2012 at 03:26:10 UTC, Jonathan M Davis
wrote:
> And when we argued for altering it so that it operated like const ref in C++
> (which allows const ref in D to continue to function like it does now), some
> folks complained, because they've found the current semantics of auto ref to
> be useful (something to do with propagating the exact, original type, I
> think).

I would expect that auto ref for a template and for a non
template should work in exactly the same way, so why would there
be a difference? If there must be a difference, there should be
different semantics for specifying the difference, otherwise the
inconsistent behaviours among identical semantics will only serve
to confuse people.

--rt