[Bug libstdc++/58605] atomic<T>::atomic() disobeys [atomics.types.operations.req]p4 for types with user-defined default constructors

["daniel.kruegler at googlemail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58605

--- Comment #1 from Daniel KrÃgler <daniel.kruegler at googlemail dot com> ---
Re initialization: I would think that the usage of "uninitialized state" is a
wording issue that should better be clarified by a library issue. I don't think
that the reference to C compatibility can be applied to structs with
non-trivial constructors, because such beasts don't exist in C. If the library
really intents to specify that a non-trivial default constructor should not be
called in this, I would strongly suggest to ammend
[atomics.types.operations.req] p4 to mention that *never* a constructor will be
called. My understanding of the mental model here has always been that it was
referring to C- compatible (POD types) where this issue doesn't arise.

On the other hand, if my understaidng is correct, I also suggest an improvement
of the existing wording to speak of "default-initialization" instead, when this
was supposed to be meant. I'll submit an LWG issue for this.

Re noexcept: The issue with exception specifications on defaulted constructors
had been discussed by the core language group exactly because of atomic<> due
to

http://cplusplus.github.io/LWG/lwg-active.html#2165

Note that the acceptance of this for atomic<> seems to indicate for me that
indeed default-initialization is intended here, otherwise the issue would be
NAD. The core language currently suggests to resolve this issue by marking the
defaulted constructor as deleted, when the exception specification violates, so
there seems no need for magic "no-initialization" in atomic.