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));

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.

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!

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.

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.

Fixed, thanks again for catching this divergence from the wording.

(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.