On Friday, 29 September 2023 06:56:34 PDT Arthur O'Dwyer via Std-Proposals
wrote:
> But wait — is it futureproof to assume that constexpr time will only *ever*
> have one thread? If someone wanted constexpr std::thread or std::async
> today, could we let them have it? If we prematurely assume that `atomic` or
> `shared_ptr` can just *ignore* atomicness at constexpr time, are we
> blocking off the avenue to constexpr `thread`?

If we ever consider the ability to start or at least simulate threads in
constexpr contexts, it will be with a hard description on how it shall be
deterministic. So I'm not worried about that when it comes to being able to
use atomic types in constexpr contexts.

Plus, there's no need to write anything specific about how to interpret
constexpr atomics: they can remain atomic. There's nothing special about them.
In fact, one could argue that in constexpr, all variable accesses are already
atomic.

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