On Mon, Feb 16, 2026 at 8:30 AM Vittorio Romeo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> [...]
> 1. There's no guarantee that `std::latch` uses atomics under the hood
> 2. There's no guarantee that `std::latch` is "lock-free"
> 3. All functions in the first pattern were `noexcept`, while none of the
> `latch`'s functions are
>
> I would like to be able to use the higher-level pattern using `std::latch`
> without sacrificing performance nor exception safety.
>
> It would be nice if there was a way to detect at compile-time if
> `std::latch` uses atomic operations under the hood and is guaranteed to not
> throw.
> Something like `std::atomic<T>::is_always_lock_free`, but for latches.
>

What is the status quo today? Are you currently unable to use
- libstdc++?
- libc++?
- MS STL?
for this reason?
*If not,* then this is not a real problem and doesn't require any
additional complexity in the paper standard to solve. Just use std::latch
and be happy.
*If so,* then how do you propose we get to a world where you can write the
code you need to write? I mean, it's no good just *detecting* that your
program can't use, say, libstdc++. What are you going to do instead? Just
fail to compile on libstdc++? What's your long-term plan here? If it's
"shame libstdc++ (or whoever) into providing a better latch," that's great,
but again I don't see how changing the paper standard is going to help you.


[...] Additionally, it would be nice if the Standard mentioned that while
> `std::latch`'s functions cannot be generally be marked `noexcept`, they
> are guaranteed to never throw if the above trait is true.
>

In general, STL vendors should mark these functions `noexcept` iff they
cannot throw. Vendors already have blanket permission to add `noexcept` to
function signatures, and they already do this for some functions, although
I'll admit it's mostly just the *special* member functions. Still, if I
knew that my vendor's `std::latch::count_down()` physically could not
throw, and yet my vendor failed to mark it `noexcept`, I'd file a bug
report and get it fixed.

If you're really looking for some way to shoehorn WG21 into the critical
path here, I suggest that you start by surveying and/or shaming STL vendors
into providing non-throwing `latch` implementations; and then you can bring
a paper that simply adds `noexcept` to the paper spec, under the banner of
"standardizing existing practice." (Compare P3016 §3.1
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3016r6.html#experience-p3623>
.)

–Arthur