On Tuesday, 12 March 2024 07:48:43 PDT Andrei Grosu via Std-Proposals wrote:
> We have a std::atomic_is_lock_free which , in my opinion, is a kind of
> feature gating: if the implementation of atomic<T> is not lock free (ie
> just syntactic sugar over a mutex or something) you can tell. Again, not
> apples to apples but frankly it is confusing from a language design pov…

The behaviour of std::atomic is the same regardless of the implementation. The
Standard does not require the implementation to be fast or that it be natively
supported by the processor. It only describes behaviour. That's what your
proposal needs to do: describe the behaviour that the feature should provide.

That constexpr boolean informs the developer about an implementation detail
because we have experience saying that it's possible to deploy different
algorithms that are more efficient than a locked atomic (in particular when
multiple atomics must be used in sequence). We have std::mutex::native_handle
because we have experience saying that it's often useful. Similarly, we have
throwing and non-throwing functions in std::filesystem because we have
experience saying developers often want the non-throwing versions.

We don't have experience with your feature yet to say what implementation
details need to be provided. And of course, in a constexpr scenario, there
shouldn't be any implementation details that are visible to the user. It
should produce the same result, every time, for everyone.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Principal Engineer - Intel DCAI Cloud Engineering