Proposed resolution:

1. Update [atomics.types.operations.req] p. 5 as follows:

   constexpr A::A(C desired);
   

   5 Effects: Initializes the object with the value desired. [ Note: Construction is not atomic. — end note ] Initialization is not an atomic operation (1.10) [intro.multithread]. [Note: It is possible to have an access to an atomic object A race with its construction, for example by communicating the address of the just-constructed object A to another thread via memory_order_relaxed atomic operations on a suitable atomic pointer variable, and then immediately accessing A in the receiving thread. This results in undefined behavior. — end note]

2. In response to the editor comment to [atomics.types.operations.req] p. 8: The first Effects element is the correct and intended one:

   void atomic_init(volatile A *object, C desired);
   void atomic_init(A *object, C desired);
   

   8 Effects: Non-atomically initializes *object with value desired. This function shall only be applied to objects that have been default constructed, and then only once. [ Note: these semantics ensure compatibility with C. — end note ] [ Note: Concurrent access from another thread, even via an atomic operation, constitutes a data race. — end note ] [Editor's note: The preceding text is from the WD as amended by N3196. N3193 makes different changes, marked up in the paper as follows:] Effects: Dynamically initializes an atomic variable. Non-atomically That is, non-atomically assigns the value desired to *object. [ Note: this operation may need to initialize locks. — end note ] Concurrent access from another thread, even via an atomic operation, constitutes a data race.