<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2424: 29.5 should state that atomic types are not trivially copyable</title>
<meta property="og:title" content="Issue 2424: 29.5 should state that atomic types are not trivially copyable">
<meta property="og:description" content="C++ library issue. Status: Resolved">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2424.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#Resolved">Resolved</a> status.</em></p>
<h3 id="2424"><a href="lwg-defects.html#2424">2424</a>. 29.5 should state that atomic types are not trivially copyable</h3>
<p><b>Section:</b> 32.5.8 <a href="https://wg21.link/atomics.types.generic">[atomics.types.generic]</a> <b>Status:</b> <a href="lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2014-08-14 <b>Last modified:</b> 2017-03-12</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Otherwise, one could use <code>memcpy</code> to save and restore the value according to 3.9p2.
<p/>
It seems the core language rules in 11 <a href="https://wg21.link/class">[class]</a>p6 with  [class.copy]p12 
(trivial copy constructor) etc. and 9.6.2 <a href="https://wg21.link/dcl.fct.def.default">[dcl.fct.def.default]</a>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 32.5.8 <a href="https://wg21.link/atomics.types.generic">[atomics.types.generic]</a> 
that these very special types are not trivially copyable.
</p>

<p><i>[2014-11 Urbana]</i></p>

<p>
Lawrence:Definition of "trivially copyable" has been changing.
</p>
<p>
Doesn't hurt to add proposed change, even if the sentence is redundant
</p>
<p>
Move to Review.
</p>

<p><i>[2015-02 Cologne]</i></p>

<p>
GR has a minor problem with the style of the wording. VV has major issues with implementability.
</p>

<p><i>[2015-03-22, Jens Maurer responses to Cologne discussion]</i></p>

<p>
A library implementation could provide a partial specialization for <code>is_trivially_copyable&lt;atomic&lt;T&gt;&gt;</code>, 
to ensure that any such type query would return <code>false</code>.
<p/>
Assuming such a specialization would be provided, how could a conforming program observe that per 
language rules an <code>atomic</code> specialization would actually be trivially copyable if there 
is no way to call the (deleted) copy constructor or copy assignment operator?
<p/>
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 <code>memcpy</code> (and the like) on <code>atomic</code> types, since that
would invoke undefined behaviour.
</p>

<p><i>[2015-05 Lenexa, SG1 response]</i></p>

<p>
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.
</p>

<p><i>[2015-05-05 Lenexa]</i></p>

<p>Marshall: This was discussed on the telecon. Alisdair was going to write something to Mike and send it to Core.</p>
<p>Hwrd: Core says that deleted copies are trivially copyable, which makes no sense to Library people.</p>
<p>STL: There doesn't appear to be a Core issue about it.</p>

<p><i>[2015-09-11 Telecon]</i></p>

<p>Howard: currently <code>std::is_trivially_copyable&lt;std::atomic&gt;</code> is true, so this resolution would contradict reality</p>
<p>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</p>
<p>Howard: is it reasonable to memcpy something that isn't trivially copy constructible or trivially assignable?</p>
<p>Jonathan: no, it's not, but Core says you can, so this resolution is needed to stop people memcpying atomic</p>
<p>Howard: we should fix the core rule</p>
<p>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</p>
<p>Howard: so should implementations specialize <code>is_trivially_copyable</code> the trait to meet this?</p>
<p>Jonathan: or add an empty, user-defined destructor.</p>
<p>Howard: should the spec specify that then?</p>
<p>Over-specification.</p>
<p>Howard: without that I fear implementation divergence.</p>
<p>Ville and Jonathan to investigate potential implementation options.</p>
<p>Ville: request a note on the issue saying we need review other types such as <code>condition_variable</code> to see if they are also unintentionally trivially-copyable. N4460 mentions some such types.</p>

<p><i>[2016-03 Jacksonville]</i></p>

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

<p><i>[2016-03 Jacksonville]</i></p>

<p>This was resolved by Core Issue 1496</p>

<p><i>[2017-01-19 Jens Maurer comments, issue state to Review]</i></p>

<p>
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.
</p>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<ol>
<li><p>Change 32.5.8 <a href="https://wg21.link/atomics.types.generic">[atomics.types.generic]</a>p3 as indicated:</p>

<blockquote>
<p>
Specializations and instantiations of the <code>atomic</code> template shall have a deleted copy constructor, a deleted
copy assignment operator, and a constexpr value constructor. <ins>They are not trivially copyable 
types (6.9 <a href="https://wg21.link/basic.types">[basic.types]</a>).</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2017-01-27 Telecon]</i></p>

<p>Resolved as NAD.</p>

<p><i>[2017-02-02 Daniel comments and adjusts status]</i></p>

<p>
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.
</p>


<p id="res-2424"><b>Proposed resolution:</b></p>





</body>
</html>
