[Bug c++/40486] New: [c++0x] rvalue-references no longer bind to lvalues

[Bug c++/40486] New: [c++0x] rvalue-references no longer bind to lvalues

[dragan at plusplus dot co dot yu]

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.


-- 
           Summary: [c++0x] rvalue-references no longer bind to lvalues
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: trivial
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dragan at plusplus dot co dot yu
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486

[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2009-06-18 11:57 -------
Let's CC Jason...


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486

[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues

[jwakely dot gcc at gmail dot com]

------- Comment #2 from jwakely dot gcc at gmail dot com  2009-06-18 13:11 -------
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!)


-- 

jwakely dot gcc at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely dot gcc at gmail dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486

[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues

[jwakely dot gcc at gmail dot com]

------- Comment #3 from jwakely dot gcc at gmail dot com  2009-06-18 13:13 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486

[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues

[dragan at plusplus dot co dot yu]

------- Comment #4 from dragan at plusplus dot co dot yu  2009-06-18 14:19 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486

[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues

[jwakely dot gcc at gmail dot com]

------- Comment #5 from jwakely dot gcc at gmail dot com  2009-06-18 15:39 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486

[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues

[jason at redhat dot com]

------- Comment #6 from jason at redhat dot com  2009-06-18 16:26 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486

[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues

[dragan at plusplus dot co dot yu]

------- Comment #7 from dragan at plusplus dot co dot yu  2009-06-18 17:09 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486

[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues

[dragan at plusplus dot co dot yu]

------- Comment #8 from dragan at plusplus dot co dot yu  2009-06-19 12:05 -------
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...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486

[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues

[jwakely dot gcc at gmail dot com]

------- Comment #9 from jwakely dot gcc at gmail dot com  2009-06-23 18:40 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486

[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues

[jwakely dot gcc at gmail dot com]

------- Comment #10 from jwakely dot gcc at gmail dot com  2009-06-30 12:10 -------
Dragan, http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054 tracks
the issue


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486

[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues

[paolo dot carlini at oracle dot com]

------- Comment #11 from paolo dot carlini at oracle dot com  2009-08-01 09:44 -------
Fixed by:

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

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


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486