[Bug libstdc++/112876] New: rangesc.end() is unnecessarily assigned by the return value of c.emplace()

[Bug libstdc++/112876] New: rangesc.end() is unnecessarily assigned by the return value of c.emplace()

[hewillk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876

            Bug ID: 112876
           Summary: rangesc.end() is unnecessarily assigned by the return
                    value of c.emplace()
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hewillk at gmail dot com
  Target Milestone: ---

[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()

[hewillk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876

康桓瑋 <hewillk at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|rangesc.end() is            |ranges:to: c.end() is
                   |unnecessarily assigned by   |unnecessarily assigned by
                   |the return value of         |the return value of
                   |c.emplace()                 |c.emplace()

--- Comment #1 from 康桓瑋 <hewillk at gmail dot com> ---
which is not guaranteed to be well-formed.

#include <ranges>

struct R {
  std::string insert(int, int);
  int end();
};
auto r = std::ranges::to<R>(std::views::single(0));

[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()

[hewillk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876

--- Comment #2 from 康桓瑋 <hewillk at gmail dot com> ---
I believe the above is well-formed after LWG 4016. 

In addition, container-appendable requires `c.emplace(c.end(), *it)` to be
well-formed but `auto end = c.end(); c.emplace(end, *it);` may not be.

Sorry for the pedantic.

[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-12-08
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, I think I should fix this. But I'm checking with LWG whether we want to
change the issue's proposed resolution to use the iterator this way.

My feeling is that we should not do this, and I should just fix the libstdc++
code.

Thanks for pointing it out!

[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
D'oh, I didn't even reuse the returned iterator, as the 'auto end = c.end();'
statement is inside the loop, so it's completely pointless.

[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876

--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:a314edee2490259d7f7caec8eef77846bcdb608b

commit r14-6357-ga314edee2490259d7f7caec8eef77846bcdb608b
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Dec 8 13:47:04 2023 +0000

    libstdc++: Fix resolution of LWG 4016 for std::ranges::to [PR112876]

    What I implemented in r14-6199-g45630fbcf7875b does not match what I
    proposed for LWG 4016, and it imposes additional, unwanted requirements
    on the emplace and insert member functions of the container being
    populated.

    libstdc++-v3/ChangeLog:

            PR libstdc++/112876
            * include/std/ranges (ranges::to): Do not try to use an iterator
            returned by the container's emplace or insert member functions.
            * testsuite/std/ranges/conv/1.cc (Cont4::emplace, Cont4::insert):
            Use the iterator parameter. Do not return an iterator.

[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed, thanks again for catching this divergence from the wording.

[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()

[hewillk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876

--- Comment #7 from 康桓瑋 <hewillk at gmail dot com> ---
(In reply to Jonathan Wakely from comment #6)
> Fixed, thanks again for catching this divergence from the wording.

Although the status of this LWG 4016 has not been updated on github, I can
assume that it has been accepted by LWG, right?
In addition, I would like to mention that `using _RefT =
range_reference_t<_Rg>;` in ranges#L9286 can be removed because there is no
place to use it.