[ 2017-02-02 Daniel comments and adjusts status ]

The NAD resolution is inappropriate, because the group didn't argue against the actual issue, instead the situation was that core wording changes in an unrelated area had resolved the previous problem indirectly. In this cases the correct resolution is Resolved by core wording changes as described by Jens Maurer in the 2017-01-19 comment.

[ 2017-01-27 Telecon ]

Resolved as NAD.

[ 2017-01-19 Jens Maurer comments, issue state to Review ]

The previous entry "[2016-03 Jacksonville] This was resolved by Core Issue 1496" is wrong; Core issue 1496 only modified the definition of "trivial class", not of "trivially copyable". However, as Ville Voutilainen observed, Core Issue 1734 made all atomics not trivially copyable, because they do not have at least one non-deleted copy/move constructor or copy/move assignment operator.

Previous resolution [SUPERSEDED]:

1. Change [atomics.types.generic]p3 as indicated:

   Specializations and instantiations of the atomic template shall have a deleted copy constructor, a deleted copy assignment operator, and a constexpr value constructor. They are not trivially copyable types ([basic.types]).

[ 2016-03 Jacksonville ]

This was resolved by Core Issue 1496

[ 2016-03 Jacksonville ]

We think there is something coming from Core to resolve that, and that this will be NAD.
Until then, defer.

[ 2015-09-11 Telecon ]

Howard: currently std::is_trivially_copyable<std::atomic> is true, so this resolution would contradict reality

Jonathan: changing that is good, we don't want it to be trivially copyable, otherwise users can memcpy them, which we really don't want

Howard: is it reasonable to memcpy something that isn't trivially copy constructible or trivially assignable?

Jonathan: no, it's not, but Core says you can, so this resolution is needed to stop people memcpying atomic

Howard: we should fix the core rule

Marshall: there is a separate issue of whether trivially-copyable makes sense, but this resolution is a net good purely because it stops memcpy of atomics

Howard: so should implementations specialize is_trivially_copyable the trait to meet this?

Jonathan: or add an empty, user-defined destructor.

Howard: should the spec specify that then?

Over-specification.

Howard: without that I fear implementation divergence.

Ville and Jonathan to investigate potential implementation options.

Ville: request a note on the issue saying we need review other types such as condition_variable to see if they are also unintentionally trivially-copyable. N4460 mentions some such types.

[ 2015-05-05 Lenexa ]

Marshall: This was discussed on the telecon. Alisdair was going to write something to Mike and send it to Core.

Hwrd: Core says that deleted copies are trivially copyable, which makes no sense to Library people.

STL: There doesn't appear to be a Core issue about it.

[ 2015-05 Lenexa, SG1 response ]

SG1 is fine with P/R (and agrees it's needed), but LWG may want to check the details; it's not entirely an SG1 issue.

[ 2015-03-22, Jens Maurer responses to Cologne discussion ]

A library implementation could provide a partial specialization for is_trivially_copyable<atomic<T>>, to ensure that any such type query would return false.

Assuming such a specialization would be provided, how could a conforming program observe that per language rules an atomic specialization would actually be trivially copyable if there is no way to call the (deleted) copy constructor or copy assignment operator?

The sole effect of the suggested addition of the constraining sentence is that it would make a user program non-conforming that attempts to invoke memcpy (and the like) on atomic types, since that would invoke undefined behaviour.

[ 2015-02 Cologne ]

GR has a minor problem with the style of the wording. VV has major issues with implementability.

[ 2014-11 Urbana ]

Lawrence:Definition of "trivially copyable" has been changing.

Doesn't hurt to add proposed change, even if the sentence is redundant

Move to Review.

Otherwise, one could use memcpy to save and restore the value according to 3.9p2.

It seems the core language rules in [class]p6 with [class.copy]p12 (trivial copy constructor) etc. and [dcl.fct.def.default]p5 (user-provided) say that the atomic types are trivially copyable, which is bad. We shouldn't rely on future core changes in that area and simply say in the library section [atomics.types.generic] that these very special types are not trivially copyable.