|
| 1 | +<?xml version='1.0' encoding='utf-8' standalone='no'?> |
| 2 | +<!DOCTYPE issue SYSTEM "lwg-issue.dtd"> |
| 3 | + |
| 4 | +<issue num="4169" status="New"> |
| 5 | +<title><tt>std::atomic<T></tt>'s default constructor should be constrained</title> |
| 6 | +<section><sref ref="[atomics.types.operations]"/></section> |
| 7 | +<submitter>Giuseppe D'Angelo</submitter> |
| 8 | +<date>15 Oct 2024</date> |
| 9 | +<priority>99</priority> |
| 10 | + |
| 11 | +<discussion> |
| 12 | +<p> |
| 13 | +The current wording for `std::atomic`'s default constructor in |
| 14 | +<sref ref="[atomics.types.operations]"/> specifies: |
| 15 | +</p> |
| 16 | +<blockquote> |
| 17 | +<pre> |
| 18 | +constexpr atomic() noexcept(is_nothrow_default_constructible_v<T>); |
| 19 | +</pre> |
| 20 | +<blockquote> |
| 21 | +<p> |
| 22 | +<i>Mandates</i>: <tt>is_default_constructible_v<T></tt> is <tt>true</tt>. |
| 23 | +</p> |
| 24 | +</blockquote> |
| 25 | +</blockquote> |
| 26 | +<p> |
| 27 | +This wording has been added by <paper num="P0883R2"/> for C++20, which changed |
| 28 | +`std::atomic`'s default constructor to always value-initialize. Before, |
| 29 | +the behavior of this constructor was not well specified (this was LWG |
| 30 | +issue <iref ref="2334"/>). |
| 31 | +<p/> |
| 32 | +The usage of a <i>Mandates</i> element in the specification has as a |
| 33 | +consequence that <tt>std::atomic<T></tt> is always default constructible, even |
| 34 | +when <tt>T</tt> is not. For instance: |
| 35 | +</p> |
| 36 | +<blockquote> |
| 37 | +<pre> |
| 38 | +// not default constructible: |
| 39 | +struct NDC { NDC(int) {} }; |
| 40 | + |
| 41 | +static_assert(std::is_default_constructible<std::atomic<NDC>>); // OK |
| 42 | +</pre> |
| 43 | +</blockquote> |
| 44 | +<p> |
| 45 | +The above check is OK as per language rules, but this is user-hostile: |
| 46 | +actually using <tt>std::atomic<NDC></tt>'s default constructor results in an |
| 47 | +error, despite the detection saying otherwise. |
| 48 | +<p/> |
| 49 | +Given that <tt>std::atomic<T></tt> already requires <tt>T</tt> to be complete anyhow |
| 50 | +(<sref ref="[atomics.types.generic.general]"/> checks for various type properties |
| 51 | +which require completeness) it would be more appropriate to use a |
| 52 | +constraint instead, so that <tt>std::atomic<T></tt> is default constructible if |
| 53 | +and only if <tt>T</tt> also is. |
| 54 | +</p> |
| 55 | +</discussion> |
| 56 | + |
| 57 | +<resolution> |
| 58 | +<p> |
| 59 | +This wording is relative to <paper num="N4993"/>. |
| 60 | +</p> |
| 61 | + |
| 62 | +<ol> |
| 63 | +<li><p>Modify <sref ref="[atomics.types.operations]"/> as indicated:</p> |
| 64 | + |
| 65 | +<blockquote class="note"> |
| 66 | +<p> |
| 67 | +[<i>Drafting note</i>: There is implementation divergence at the moment; libstdc++ already |
| 68 | +implements the proposed resolution and has done so for a while.] |
| 69 | +</p> |
| 70 | +</blockquote> |
| 71 | + |
| 72 | +<blockquote> |
| 73 | +<pre> |
| 74 | +constexpr atomic() noexcept(is_nothrow_default_constructible_v<T>); |
| 75 | +</pre> |
| 76 | +<blockquote> |
| 77 | +<p> |
| 78 | +-1- <i><ins>Constraints</ins><del>Mandates</del></i>: <tt>is_default_constructible_v<T></tt> is <tt>true</tt>. |
| 79 | +<p/> |
| 80 | +-2- <i>Effects</i>: […] |
| 81 | +</p> |
| 82 | +</blockquote> |
| 83 | +</blockquote> |
| 84 | + |
| 85 | +</li> |
| 86 | +</ol> |
| 87 | +</resolution> |
| 88 | +</issue> |
0 commit comments