[...]
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.)
–Arthur