On Wed, 2 Jul 2025 at 02:25, Howard Hinnant via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Jul 1, 2025, at 5:03 PM, Jonathan Wakely via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> > See
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3182r1.html
> >
>
> I’ve prototyped the solution in
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3182r1.html and
> it only works if the value_type move constructor has the strong exception
> safety guarantee. If it has only the basic exception safety guarantee, the
> pop_value implementation in section 6.1 still loses the value on
> exception. This completely negates the argument that we have the
> technology now to workaround the C++98 concerns regarding exception safety.
>
> The only way I see to make pop_value exception safe is for it to require
> is_nothrow_move_constructible_v<value_type>. *Then* we fully negate the
> C++98 exception safety issue. And then the Guard is not needed (as noted
> in P3182).
>

I think you also need the underlying container's pop_back() to be
non-throwing. None of our existing sequence containers have a noexcept
pop_back(), because of the Lakos rule.

I wrote a draft proposal for std::stack::pop() a few years ago that I never
finished writing and abandoned because of the problem with a
potentially-throwing pop_back:
https://isocpp.org/files/papers/D2518R0.html