Bug 40486 - [c++0x] rvalue-references no longer bind to lvalues
Summary: [c++0x] rvalue-references no longer bind to lvalues
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.5.0
: P3 trivial
Target Milestone: 4.5.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-18 11:52 UTC by Dragan Milenkovic
Modified: 2009-08-01 09:44 UTC (History)
3 users (show)

See Also:
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dragan Milenkovic 2009-06-18 11:52:11 UTC
I'm surprised this hasn't been implemented already. AFAIK, it was
accepted and is in the current draft.

http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00436.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html

The patch still applies to the compiler itself. However, the patch
doesn't handle issues addressed in update from N2831. Also, library
part doesn't apply, although I believe it would be trivial to update.
Comment 1 Paolo Carlini 2009-06-18 11:57:31 UTC
Let's CC Jason...
Comment 2 Jonathan Wakely 2009-06-18 13:11:01 UTC
I've already done the library parts on trunk, see http://gcc.gnu.org/ml/libstdc++/2009-05/msg00114.html
I'll review Doug's patch to see if I missed anything. 

N.B. the changes to std::move and std::forward were *not* accepted into the WP yet, I think there's ongoing work in that area.  Because of that, I'm not sure what would happen if the front end changes were applied (I think the current definitions of std::move and std::forward would break large parts of the library!)
Comment 3 Jonathan Wakely 2009-06-18 13:13:59 UTC
Also, n2844 and Doug's patch don't update std::make_pair, so it won't accept lvalues according to the current draft.  That needs fixing too.
Comment 4 Dragan Milenkovic 2009-06-18 14:19:36 UTC
(In reply to comment #3)
> Also, n2844 and Doug's patch don't update std::make_pair, so it won't accept
> lvalues according to the current draft.  That needs fixing too.
> 

If you are referring to:

template <MoveConstructible T1, MoveConstructible T2>
  pair<V1, V2> make_pair(T1&& x, T2&& y);

I'm not into concepts yet (the reason being obvious :-), but I think
T1,T2 can be lvalue-references. Unfortunately, in this case, under
reference collapsing rules, this _will_ accept lvalues and perfectly forward
them to the pair constructor.

Am I off the track here? As for deducing pair template parameters as described
in WP, I can only see symptoms of "coding under influence" :-D

I say "unfortunately" above, because I don't like the syntax (namely &&)
used to express a function that can take both lvalues and rvalues.
I have objected on comp.std.c++, but got no real support.

Also, about move and forward. IMHO, those presented in the patch
seem fine. Did I understand correctly that the only thing you
are waiting is acceptance into WP? I guess the functionality will
remain the same. It might be they have issues with concepts.
I'm only guessing, so I apologize if you have some _solid_ information.
Comment 5 Jonathan Wakely 2009-06-18 15:39:44 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Also, n2844 and Doug's patch don't update std::make_pair, so it won't accept
> > lvalues according to the current draft.  That needs fixing too.
> > 
> 
> If you are referring to:
> 
> template <MoveConstructible T1, MoveConstructible T2>
>   pair<V1, V2> make_pair(T1&& x, T2&& y);
> 
> I'm not into concepts yet (the reason being obvious :-), but I think
> T1,T2 can be lvalue-references. Unfortunately, in this case, under
> reference collapsing rules, this _will_ accept lvalues and perfectly forward
> them to the pair constructor.

Ah, OK, I hadn't understood that correctly, thanks for the explanation.
 
> Am I off the track here? As for deducing pair template parameters as described
> in WP, I can only see symptoms of "coding under influence" :-D

I'm not sure, so I'll take your word for it :-) 

> I say "unfortunately" above, because I don't like the syntax (namely &&)
> used to express a function that can take both lvalues and rvalues.
> I have objected on comp.std.c++, but got no real support.

> Also, about move and forward. IMHO, those presented in the patch
> seem fine. Did I understand correctly that the only thing you
> are waiting is acceptance into WP? I guess the functionality will
> remain the same. It might be they have issues with concepts.
> I'm only guessing, so I apologize if you have some _solid_ information.

Yes, I was just pointing out that the WP currently doesn't have the changes to std::forward and std::move - I don't know why, or what the final versions might look like.

Comment 6 Jason Merrill 2009-06-18 16:26:23 UTC
Subject: Re:  [c++0x] rvalue-references no longer bind to lvalues

On 06/18/2009 11:39 AM, jwakely dot gcc at gmail dot com wrote:
> Yes, I was just pointing out that the WP currently doesn't have the changes to
> std::forward and std::move - I don't know why, or what the final versions might
> look like.

Because there were strong objections to those changes at the meeting. 
People have been working on a different solution.
Comment 7 Dragan Milenkovic 2009-06-18 17:09:17 UTC
(In reply to comment #6)
> Because there were strong objections to those changes at the meeting. 
> People have been working on a different solution.

I know this is a bad place to continue the discussion on this topic,
so I would like to know if there are any documents or articles, or other
ways to get involved into the matter? Are people objecting the whole
lvalue/rvalue-reference solution, or only move/forward part and why?

The only relevant thread on comp.std.c++ I could find is
"Catch by rvalue reference" that continues to
"std::move and lvalues (was: re: catch by rvalue reference)"
... but nothing there...

Thanks.
Comment 8 Dragan Milenkovic 2009-06-19 12:05:30 UTC
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2837.pdf

page 40 - clause 8.5.3
page 41 - clauses 12.1, 12.4, 12.8

My vote goes to the first option.

Guess we'll wait and see...
Comment 9 Jonathan Wakely 2009-06-23 18:40:11 UTC
The library pieces of Doug's patch that still need to be applied are:

	* include/std/tuple (_Tuple_impl): Use lvalue references when
	explicitly specifying the template argument to std::move.

	* include/std/iosfwd (operator<<): Provide a forwarding operator<<
	that accepts rvalue streams.
	(operator>>): Ditto.

	* include/bits/stl_iterator.h (move_iterator::operator*):
	Explicitly std::move the result, to convert it to an rvalue
	reference.

	* include/bits/stl_move.h (forward): Forward lvalues (which may
	end up being turned into rvalues).
	(move): Explicitly static_cast to an rvalue.

	* testsuite/27_io/rvalue_streams.cc: New; test the use of rvalue
	streams. Works except for the fact that we can't call str() on the
	result. (This is an existing issue).

I think the move_iterator and tuple changes would be OK to apply now but the stream parts have a FIXME and as discussed, the definition of std::move is undecided.  I'll come back to this soon.
Comment 10 Jonathan Wakely 2009-06-30 12:10:44 UTC
Dragan, http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054 tracks the issue
Comment 11 Paolo Carlini 2009-08-01 09:44:14 UTC
Fixed by:

  http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00001.html

If I'm missing some detail, please reopen, thanks!