On Wed, Jul 2, 2025 at 12:04 PM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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

https://github.com/dascandy/s2/blob/master/include/s2/detail/vector.h#L123

It's definitely a thing that's possible to implement, but it indeed
requires full control over the type's implementation, and it strictly
requires nothrow destructible. I do believe that the implementation I
linked is safe for types that can throw on move, with the caveat that if
you have such a queue or stack and fail to pop the value off... then what?

As far as I can tell the backward compatibility issues, lack of marked
improvement and minor details are what's holding this back, but practically
it seems viable.