View mode: basic / threaded / horizontal-split · Log in · Help
October 22, 2012
Re: Const ref and rvalues again...
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.)
October 22, 2012
Re: Const ref and rvalues again...
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.
October 22, 2012
Re: Const ref and rvalues again...
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.
November 04, 2012
Re: Const ref and rvalues again...
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
November 05, 2012
Re: Const ref and rvalues again...
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.).
November 05, 2012
Re: Const ref and rvalues again...
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?
November 05, 2012
Re: Const ref and rvalues again...
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
November 05, 2012
Re: Const ref and rvalues again...
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
November 05, 2012
Re: Const ref and rvalues again...
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.
November 05, 2012
Re: Const ref and rvalues again...
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
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home