Alternatively new latch classes with different guarantees or constructor parameters of latch (if size and members would be the same) could work.   Better than checking, whether it has guarantees is choosing the one with a guarantee.   -----Ursprüngliche Nachricht----- Von:Vittorio Romeo via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 16.02.2026 14:30 Betreff:[std-proposals] RFC: a way to check if `std::latch` is implemented with atomics An:std-proposals_at_[hidden]; CC:Vittorio Romeo <vittorio.romeo_at_[hidden]>; Consider the following pattern: std::atomic_flag flag = ATOMIC_FLAG_INIT; // Thread A flag.test_and_set(std::memory_order_release); flag.notify_all(); // Thread B flag.wait(false, std::memory_order_acquire); It can nicely be simplified with a latch: std::latch latch{ 1 }; // Thread A latch.count_down(); // Thread B latch.wait(); This seems a direct improvement, but unfortunately it really isn't: 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.   Ideas: - std::latch::is_always_lock_free - std::latch::uses_atomic_operations - std::latch::is_atomic   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.   What do you think? Worth writing a paper?   Cheers, Vittorio Romeo https://vittorioromeo.com -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals