On Jul 1, 2025, at 5:03 PM, Jonathan Wakely via Std-Proposals <std-proposals@lists.isocpp.org> 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: