Date: Tue, 1 Jul 2025 21:24:29 -0400
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).
Howard
>
> 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).
Howard
Received on 2025-07-02 01:25:04