<pre class='metadata'>
Title: Deprecating <code>volatile</code>
Shortname: P1152
Revision: 1
Audience: SG1, LEWG, EWG
Status: P
Group: WG21
URL: http://wg21.link/P1152R1
!Source: <a href="https://github.com/jfbastien/papers/blob/master/source/P1152R1.bs">github.com/jfbastien/papers/blob/master/source/P1152R1.bs</a>
Editor: JF Bastien, Apple, jfbastien@apple.com
No abstract: true
Date: 2019-01-20
Markup Shorthands: markdown yes
</pre>

<style>
blockquote.book {
  display: block;
  border-width: 2px 0;
  border-style: solid;
  border-color: #eee;
  padding: 1.5em 5em 0.5em 5em;
  margin: 1.5em 0;
  position: relative;
  text-align: justify;
}
blockquote.book:before {
  content: '\201C';
  position: absolute;
  top: 0em;
  left: 50%;
  transform: translate(-50%, -50%);
  background: #fff;
  width: 3rem;
  height: 2rem;
  font: 6em/1.08em 'PT Sans', sans-serif;
  color: #666;
  text-align: center;
}
blockquote.book:after {
  content: '\201D';
  position: absolute;
  bottom: -0.25em;
  left: 50%;
  transform: translate(-50%, -50%);
  background: #fff;
  width: 3rem;
  height: 2rem;
  font: 6em/1.08em 'PT Sans', sans-serif;
  color: #666;
  text-align: center;
}
cite {
  display: block;
  text-align: right;
  color: #e74c3c;
  margin: 0 -5em 1em 0;
}
th { vertical-align: middle; }
</style>

Abstract {#abstract}
========

We propose deprecating most of `volatile`. See [[#word]] for the details.

The proposed deprecation preserves the useful parts of `volatile`, and removes
the dubious / already broken ones. This paper aims at breaking at compile-time
code which is today subtly broken at runtime or through a compiler update. The
paper might also break another type of code: that which doesn't exist. This
removes a significant foot-gun and removes unintuitive corner cases from the
languages.

The first version of this paper, [[P1152R0]], has extensive background
information which is not repeated here:

  * <a href="wg21.link/P1152R0#over">Overview</a>
  * <a href="wg21.link/P1152R0#where">How we got here</a>
  * <a href="wg21.link/P1152R0#why">Why the proposed changes?</a>
  * <a href="wg21.link/P1152R0#examples">Examples</a>

See [[P1382R0]] for the follow-up paper on `volatile_load<T>` /
`volatile_store<T>` requested by SG1.


Edit History {#edit}
============

r0 → r1 {#r0r1}
-------

[[P1152R0]] was seen by SG1 and EWG in San Diego. This update does the
following:

  * Remove background information from the paper.
  * Follow the guidance from SG1 and EWG, based on the polls below.

<table>
    <thead>
        <tr>
            <th>Poll</th>
            <th>Group</th>
            <th>SF</th>
            <th>F</th>
            <th>N</th>
            <th>A</th>
            <th>SA</th>
            <th>Outcome</th>
        </tr>
    </thead>
    <tr>
        <th>Deprecate `volatile` compound operations (including `++` and `--`) on scalar types (arithmetic, pointer, enumeration).</th>
        <th>SG1</th><th>4</th><th>19</th><th>3</th><th>0</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>Deprecate `volatile` compound operations (including `++` and `--`) on scalar types (arithmetic, pointer, enumeration).</th>
        <th>EWG</th><th>4</th><th>9</th><th>4</th><th>0</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>Deprecate usage of `volatile` assignment chaining on scalar types (arithmetic, pointer, enumeration, pointer to members, `nullptr_t`).</th>
        <th>SG1</th><th>6</th><th>15</th><th>3</th><th>0</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>Deprecate usage of `volatile` assignment chaining on scalar types (arithmetic, pointer, enumeration, pointer to members, `nullptr_t`).</th>
        <th>EWG</th><th>6</th><th>9</th><th>3</th><th>0</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>SG1 would be OK if we deprecated `volatile` qualified member functions (pending separate decision on what we do with `volatile` atomic).</th>
        <th>SG1</th><th>1</th><th>5</th><th>10</th><th>4</th><th>3</th><th>❌</th>
    </tr>
    <tr>
        <th>EWG would be OK if we deprecated `volatile` qualified member functions (pending separate decision on what we do with `volatile` atomic).</th>
        <th>EWG</th><th>2</th><th>7</th><th>7</th><th>1</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>SG1 would be OK if we deprecated `volatile` partial template specializations, overloads, or qualified member functions in the STL for all but the atomic, `numeric_limits`, and type traits (`remove_volatile`, `add_volatile`, etc) parts of the Library.</th>
        <th>SG1</th><th>1</th><th>9</th><th>6</th><th>2</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>EWG would be OK if we deprecated `volatile` partial template specializations, overloads, or qualified member functions in the STL for all but the atomic, `numeric_limits`, and type traits (`remove_volatile`, `add_volatile`, etc) parts of the Library.</th>
        <th>EWG</th><th>1</th><th>11</th><th>9</th><th>0</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>Deprecate `volatile` member functions of atomic in favor of new template partial specializations which will only declare load, store, and only exist when `is_always_lock_free` is true.</th>
        <th>SG1</th><th>2</th><th>1</th><th>1</th><th>11</th><th>2</th><th>❌</th>
    </tr>
    <tr>
        <th>Deprecate `volatile` member functions of atomic in favor of new template partial specializations which will only declare load, store, RMW, and only exist when `is_always_lock_free` is true.</th>
        <th>SG1</th><th>4</th><th>7</th><th>3</th><th>3</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>Deprecate `volatile` member functions of atomic in favor of new template partial specializations which will only declare load, store, RMW, and only exist when `is_always_lock_free` is true.</th>
        <th>EWG</th><th>2</th><th>9</th><th>3</th><th>0</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>Deprecate `volatile` member functions of atomic in favor of new template partial specializations which will only declare load, store, RMW.</th>
        <th>SG1</th><th>0</th><th>0</th><th>0</th><th>10</th><th>7</th><th>❌</th>
    </tr>
    <tr>
        <th>SG1 would be OK if we deprecated top-level `volatile` parameters.</th>
        <th>SG1</th><th>6</th><th>9</th><th>6</th><th>2</th><th>1</th><th>✅</th>
    </tr>
    <tr>
        <th>EWG would be OK if we deprecated top-level `volatile` parameters.</th>
        <th>EWG</th><th>6</th><th>9</th><th>6</th><th>0</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>EWG would be OK if we deprecated top-level const parameters.</th>
        <th>EWG</th><th>0</th><th>2</th><th>5</th><th>8</th><th>8</th><th>❌</th>
    </tr>
    <tr>
        <th>SG1 would be OK if we deprecated top-level `volatile` return values.</th>
        <th>SG1</th><th>6</th><th>9</th><th>4</th><th>2</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>EWG would be OK if we deprecated top-level `volatile` return values.</th>
        <th>EWG</th><th>6</th><th>6</th><th>5</th><th>0</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>EWG would be OK if we deprecated top-level const return values.</th>
        <th>EWG</th><th>2</th><th>3</th><th>3</th><th>5</th><th>5</th><th>❌</th>
    </tr>
    <tr>
        <th>SG1 interested is interested in hearing about `volatile_load<T>` / `volatile_store<T>` free functions in a separate paper, given that time is limited and we could be doing something else.</th>
        <th>SG1</th><th>0</th><th>17</th><th>4</th><th>3</th><th>0</th><th>✅</th>
    </tr>
    <tr>
        <th>EWG interested is interested in hearing about `volatile_load<T>` / `volatile_store<T>` free functions in a separate paper, given that time is limited and we could be doing something else.</th>
        <th>EWG</th><th>2</th><th>11</th><th>4</th><th>1</th><th>0</th><th>✅</th>
    </tr>
</table>


Wording {#word}
=======

Program execution [**intro.execution**] {#intro.execution}
---------------------------------------

No changes.
  
<blockquote>

  Accesses through `volatile` glvalues are evaluated strictly according to the
  rules of the abstract machine.
  
  Reading an object designated by a `volatile` glvalue, modifying an object,
  calling a library I/O function, or calling a function that does any of those
  operations are all *side effects*, which are changes in the state of the
  execution environment. *Evaluation* of an expression (or a subexpression) in
  general includes both value computations (including determining the identity
  of an object for glvalue evaluation and fetching a value previously assigned
  to an object for prvalue evaluation) and initiation of side effects. When a
  call to a library I/O function returns or an access through a `volatile`
  glvalue is evaluated the side effect is considered complete, even though some
  external actions implied by the call (such as the I/O itself) or by the
  `volatile` access may not have completed yet.

</blockquote>

Data races [**intro.races**] {#data.races}
----------------------------
  
No changes.

<blockquote>

  Two accesses to the same object of type `volatile` `std::sig_atomic_t` do not
  result in a data race if both occur in the same thread, even if one or more
  occurs in a signal handler. For each signal handler invocation, evaluations
  performed by the thread invoking a signal handler can be divided into two
  groups A and B, such that no evaluations in B happen before evaluations in A,
  and the evaluations of such `volatile` `std::sig_atomic_t` objects take values
  as though all evaluations in A happened before the execution of the signal
  handler and the execution of the signal handler happened before all
  evaluations in B.
  
</blockquote>

Forward progress [**intro.progress**] {#intro.progress}
-------------------------------------
  
No changes.

<blockquote>

  The implementation may assume that any thread will eventually do one of the
  following:

  * terminate,
  * make a call to a library I/O function,
  * perform an access through a `volatile` glvalue, or
  * perform a synchronization operation or an atomic operation

  During the execution of a thread of execution, each of the following is termed
  an execution step:
  
  * termination of the thread of execution,
  * performing an access through a `volatile` glvalue, or
  * completion of a call to a library I/O function, a synchronization
    operation, or an atomic operation.

</blockquote>

Class member access [**expr.ref**] {#expr.ref}
----------------------------------

No changes.
  
<blockquote>

  Abbreviating *postfix-expression.id-expression* as `E1.E2`, `E1` is called the
  *object expression*. If `E2` is a bit-field, `E1.E2` is a bit-field. The type
  and value category of `E1.E2` are determined as follows. In the remainder of
  [**expr.ref**], *cq* represents either `const` or the absence of `const` and
  *vq* represents either `volatile` or the absence of `volatile`. *cv*
  represents an arbitrary set of cv-qualifiers.
  
  * If `E2` is a non-static data member and the type of `E1` is “*cq1 vq1 X*”,
    and the type of `E2` is “*cq2 vq2 T*”, the expression designates the named
    member of the object designated by the first expression. If `E1` is an
    lvalue, then `E1.E2` is an lvalue; otherwise `E1.E2` is an xvalue. Let the
    notation *vq12* stand for the “union” of *vq1* and *vq2*; that is, if *vq1*
    or *vq2* is `volatile`, then *vq12* is `volatile`. Similarly, let the
    notation *cq12* stand for the “union” of *cq1* and *cq2*; that is, if *cq1*
    or *cq2* is `const`, then *cq12* is `const`. If `E2` is declared to be a
    `mutable` member, then the type of `E1.E2` is “*vq12 T*”. If `E2` is not
    declared to be a `mutable` member, then the type of `E1.E2` is
    “*cq12 vq12 T*”.

</blockquote>

The cv-qualifiers [**dcl.type.cv**] {#dcl.type.cv}
-----------------------------------

No changes.
  
<blockquote>

  The semantics of an access through a `volatile` glvalue are
  implementation-defined. If an attempt is made to access an object defined with
  a `volatile`-qualified type through the use of a non-`volatile` glvalue, the
  behavior is undefined.

  [ *Note:* `volatile` is a hint to the implementation to avoid aggressive
  optimization involving the object because the value of the object might be
  changed by means undetectable by an implementation. Furthermore, for some
  implementations, `volatile` might indicate that special hardware instructions
  are required to access the object. See [**intro.execution**] for detailed
  semantics. In general, the semantics of `volatile` are intended to be the same
  in C++ as they are in C. —*end note* ]

</blockquote>

Functions [**dcl.fct**] {#dcl.fct}
-----------------------

Modify as follows.

<blockquote>

  The *parameter-declaration-clause* determines the arguments that can be
  specified, and their processing, when the function is called. [ *Note:* The
  *parameter-declaration-clause* is used to convert the arguments specified on
  the function call; see [**expr.call**] —*end note* ] If the
  *parameter-declaration-clause* is empty, the function takes no arguments. A
  parameter list consisting of a single unnamed parameter of non-dependent type
  `void` is equivalent to an empty parameter list. Except for this special case,
  a parameter shall not have type *cv* `void`. <ins> A parameter's *declarator*
  shall only allow `const` as its *parameters-and-qualifiers*'s
  *cv-qualifier-seq*. </ins>If the *parameter-declaration-clause* terminates
  with an ellipsis or a function parameter pack, the number of arguments shall
  be equal to or greater than the number of parameters that do not have a
  default argument and are not function parameter packs. Where syntactically
  correct and where "`...`" is not part of an *abstract-declarator*, "`, ...`"
  is synonymous with "`...`".
  
  [...]
  
  The type of a function is determined using the following rules. The type of
  each parameter (including function parameter packs) is determined from its own
  *decl-specifier-seq* and *declarator*. After determining the type of each
  parameter, any parameter of type "array of `T`" or of function type `T` is
  adjusted to be "pointer to `T`". After producing the list of parameter types,
  any top-level *cv-qualifier*s modifying a parameter type are deleted when
  forming the function type. The resulting list of transformed parameter types
  and the presence or absence of the ellipsis or a function parameter pack is
  the function's *parameter-type-list*.
  
  [...]
  
  Functions shall not have a return type of type array or function, although
  they may have a return type of type pointer or reference to such things. There
  shall be no arrays of functions, although there can be arrays of pointers to
  functions.
  
  <ins>Functions shall not have a `volatile` qualified return type.</ins>

</blockquote>

Non-static member functions [**class.mfct.non-static**] {#class.mfct.non-static}
-------------------------------------------------------

No changes.

<blockquote>

  A non-static member function may be declared `const`, `volatile`, or
  `const volatile`. These cv-qualifiers affect the type of the `this` pointer.
  They also affect the function type of the member function; a member
  function declared `const` is a `const` member function, a member function declared
  `volatile` is a `volatile` member function and a member function declared
  `const volatile` is a `const volatile` member function.

</blockquote>

The this pointer [**class.this**] {#class.this}
---------------------------------

No changes.

<blockquote>

   In the body of a non-static member function, the keyword `this` is a prvalue
   expression whose value is the address of the object for which the function is
   called. The type of `this` in a member function of a class `X` is `X*`. If
   the member function is declared `const`, the type of `this` is `const X*`, if
   the member function is declared `volatile`, the type of `this` is
   `volatile X*`, and if the member function is declared `const volatile`, the type of
   `this` is `const volatile X*`.
   
   `volatile` semantics apply in `volatile` member functions when accessing the
   object and its non-static data members.

</blockquote>

Constructors [**class.ctor**] {#class.ctor}
-----------------------------

No changes.

<blockquote>

  A constructor can be invoked for a `const`, `volatile` or `const volatile`
  object. `const` and `volatile` semantics are not applied on an object under
  construction. They come into effect when the constructor for the most derived
  object ends.

</blockquote>

Destructors [**class.dtor**] {#class.dtor}
----------------------------

No changes.

<blockquote>

  A destructor is used to destroy objects of its class type. The address of a
  destructor shall not be taken. A destructor can be invoked for a `const`,
  `volatile` or `const volatile` object. `const` and `volatile` semantics are
  not applied on an object under destruction. They stop being in effect when the
  destructor for the most derived object starts.

</blockquote>

Overloadable declarations [**over.load**] {#over.load}
-----------------------------------------

Modify as follows.

<blockquote>

  Parameter declarations that differ only in the presence or absence of
  `const` <del>and/or `volatile`</del> are equivalent. That is, the
  `const` <del>and `volatile`</del> type-specifiers for each parameter type are
  ignored when determining which function is being declared, defined, or called.

</blockquote>

Built-in operators [**over.built**] {#over.built}
-----------------------------------

Modify as follows.

<blockquote>

  <del>In the remainder of this section, *vq* represents either `volatile` or no
  cv-qualifier.</del>
  
  For every <del>pair (*T*, *vq*), where *T* is an</del> arithmetic type<ins>*T*</ins> other than `bool`,
  there exist candidate operator functions of the form

  <pre><code>
  <del>vq </del>T &amp; operator++(<del>vq </del>T &amp;);
  T operator++(<del>vq </del>T &amp;, int);
  </code></pre>

  For every <del>pair (*T*, *vq*), where *T* is an</del> arithmetic type<ins>*T*</ins> other than `bool`,
  there exist candidate operator functions of the form

  <pre><code>
  <del>vq </del>T &amp; operator--(<del>vq </del>T &amp;);
  T operator--(<del>vq </del>T &amp;, int);
  </code></pre>

  For every <del>pair (*T*, *vq*)</del><ins>*T*</ins>, where *T* is a cv-qualified or cv-unqualified
  object type, there exist candidate operator functions of the form

  <pre><code>
  T*<del>vq</del>&amp; operator++(T*<del>vq</del>&amp;);
  T*<del>vq</del>&amp; operator--(T*<del>vq</del>&amp;);
  T* operator++(T*<del>vq</del>&amp;, int);
  T* operator--(T*<del>vq</del>&amp;, int);
  </code></pre>
  
  For every quintuple (*C1*, *C2*, *T*, *cv1*, *cv2*), where *C2* is a class
  type, *C1* is the same type as *C2* or is a derived class of *C2*, and *T* is an
  object type or a function type, there exist candidate operator functions of
  the form

  <pre><code>
  cv12 T&amp; operator->*(cv1 C1*, cv2 T C2::*);
  </code></pre>
  
  For every <del>triple</del><ins>pair</ins> (*L*, <del>*vq*, </del>*R*), where *L* is an arithmetic type, and *R* is
  a promoted arithmetic type, there exist candidate operator functions of the
  form

  <pre><code>
  <ins>void operator=(volatile L&amp;, R);</ins>
  <del>vq </del>L&amp; operator=(<del>vq </del>L&amp;, R);
  <del>vq </del>L&amp; operator*=(<del>vq </del>L&amp;, R);
  <del>vq </del>L&amp; operator/=(<del>vq </del>L&amp;, R);
  <del>vq </del>L&amp; operator+=(<del>vq </del>L&amp;, R);
  <del>vq </del>L&amp; operator-=(<del>vq </del>L&amp;, R);
  </code></pre>
    
For <del>every pair (*T*, *vq*), where *T* is any type</del><ins>all types *T*</ins>, there exist candidate
  operator functions of the form
  
  <pre><code>
  <ins>void operator=(T*volatile&amp;, T*);</ins>
  T*<del>vq</del>&amp; operator=(T*<del>vq</del>&amp;, T*);
  </code></pre>

  For every <del>pair (*T*, *vq*), where *T* is an</del> enumeration or pointer to member
  type<ins> *T*</ins>, there exist candidate operator functions of the form

  <pre><code>
  <ins>void operator=(volatile T&amp;, T );</ins>
  <del>vq </del>T&amp; operator=(<del>vq </del>T&amp;, T );
  </code></pre>

  For every <del>pair (*T*, *vq*)</del><ins>*T*</ins>, where *T* is a cv-qualified or cv-unqualified
  object type, there exist candidate operator functions of the form

  <pre><code>
  T*<del>vq</del>&amp; operator+=(T*<del>vq</del>&amp;, std::ptrdiff_t);
  T*<del>vq</del>&amp; operator-=(T*<del>vq</del>&amp;, std::ptrdiff_t);
  </code></pre>

  For every <del>triple</del><ins>pair</ins> (*L*, <del>*vq*, </del>*R*), where *L* is an integral type, and *R* is a
  promoted integral type, there exist candidate operator functions of the form

  <pre><code>
  <del>vq </del>L&amp; operator%=(<del>vq </del>L&amp;, R);
  <del>vq </del>L&amp; operator<<=(<del>vq </del>L&amp;, R);
  <del>vq </del>L&amp; operator>>=(<del>vq </del>L&amp;, R);
  <del>vq </del>L&amp; operator&amp;=(<del>vq </del>L&amp;, R);
  <del>vq </del>L&amp; operator^=(<del>vq </del>L&amp;, R);
  <del>vq </del>L&amp; operator|=(<del>vq </del>L&amp;, R);
  </code></pre>

</blockquote>

Tuples [**tuple**] {#tuple}
------------------

Modify as follows.

<blockquote>

  Header `<tuple>` synopsis [**tuple.syn**]:
  
  <pre><code>
    namespace std {
    
    [...]
    
    // [<i>tuple.helper</i>, tuple helper classes
    template&lt;class T&gt; class tuple_size;                  // not defined
    template&lt;class T&gt; class tuple_size&lt;const T&gt;;
    <del>template&lt;class T&gt; class tuple_size&lt;volatile T&gt;;</del>
    <del>template&lt;class T&gt; class tuple_size&lt;const volatile T&gt;;</del>
    
    template&lt;class... Types&gt; class tuple_size&lt;tuple&lt;Types...&gt;&gt;;
    
    template&lt;size_t I, class T&gt; class tuple_element;     // not defined
    template&lt;size_t I, class T&gt; class tuple_element&lt;I, const T&gt;;
    <del>template&lt;size_t I, class T&gt; class tuple_element&lt;I, volatile T&gt;;</del>
    <del>template&lt;size_t I, class T&gt; class tuple_element&lt;I, const volatile T&gt;;</del>

    [...]
    
    }
    
  </code></pre>
  
  [...]
  
  Tuple helper classes [**tuple.helper**]

  <pre><code>
  
  template&lt;class T&gt; class tuple_size&lt;const T&gt;;
  <del>template&lt;class T&gt; class tuple_size&lt;volatile T&gt;;</del>
  <del>template&lt;class T&gt; class tuple_size&lt;const volatile T&gt;;</del>
  
  </code></pre>

  Let `TS` denote `tuple_size<T>` of the *cv*-unqualified type `T`. If the
  expression `TS::value` is well-formed when treated as an unevaluated operand,
  then each of the three templates shall satisfy the `TransformationTrait`
  requirements with a base characteristic of

  <pre><code>integral_constant&lt;size_t, TS::value&gt;</code></pre>
  
  Otherwise, they shall have no member `value`.
  
  Access checking is performed as if in a context unrelated to `TS` and `T`.
  Only the validity of the immediate context of the expression is considered. [
  *Note:* The compilation of the expression can result in side effects such as
  the instantiation of class template specializations and function template
  specializations, the generation of implicitly-defined functions, and so on.
  Such side effects are not in the "immediate context" and can result in the
  program being ill-formed. —*end note* ]

  In addition to being available via inclusion of the `<tuple>` header,
  the <del>three templates are</del><ins>template is</ins> available when any of the
  headers `<array>`, `<ranges>`, or `<utility>` are included.

  <pre><code>
  
  template&lt;size_t I, class T&gt; class tuple_element&lt;I, const T&gt;;
  <del>template&lt;size_t I, class T&gt; class tuple_element&lt;I, volatile T&gt;;</del>
  <del>template&lt;size_t I, class T&gt; class tuple_element&lt;I, const volatile T&gt;;</del>

  </code></pre>

  Let `TE` denote `tuple_element_t<I, T>` of the *cv*-unqualified type `T`.
  Then <del>each of the three templates</del><ins>the template</ins> shall satisfy
  the `TransformationTrait` requirements with a member typedef `type` that names
  the following type:<ins> `add_const_t<TE>`.</ins>

  <del><ul>
    <li>for the first specialization, `add_const_t<TE>`,
    <li>for the second specialization, `add_volatile_t<TE>`, and
    <li>for the third specialization, `add_cv_t<TE>`.
  </ul></del>

  In addition to being available via inclusion of the `<tuple>` header,
  the <del>three templates are</del><ins>template is</ins> available when any of the
  headers `<array>`, `<ranges>`, or `<utility>` are included.

</blockquote>

Variants [**variant**] {#variant}
----------------------

Modify as follows.

<blockquote>

  `<variant>` synopsis [**variant.syn**]
  
  <pre><code>
  
  namespace std {
  // [<i>variant.variant</i>], class template variant
  template&lt;class... Types&gt;
    class variant;

  // [<i>variant.helper</i>], variant helper classes
  template&lt;class T&gt; struct variant_size;                   // not defined
  template&lt;class T&gt; struct variant_size&lt;const T&gt;;
  <del>template&lt;class T&gt; struct variant_size&lt;volatile T&gt;;</del>
  <del>template&lt;class T&gt; struct variant_size&lt;const volatile T&gt;;</del>
  template&lt;class T&gt;
    inline constexpr size_t variant_size_v = variant_size&lt;T&gt;::value;

  template&lt;class... Types&gt;
    struct variant_size&lt;variant&lt;Types...&gt;&gt;;

  template&lt;size_t I, class T&gt; struct variant_alternative;  // not defined
  template&lt;size_t I, class T&gt; struct variant_alternative&lt;I, const T&gt;;
  <del>template&lt;size_t I, class T&gt; struct variant_alternative&lt;I, volatile T&gt;;</del>
  <del>template&lt;size_t I, class T&gt; struct variant_alternative&lt;I, const volatile T&gt;;</del>

  [...]
  
  }
  
  </code></pre>
  
  `variant` helper classes [**variant.helper**]
  
  <pre><code>template&lt;class T&gt; struct variant_size;</code></pre>

  *Remark:* All specializations of `variant_size` shall satisfy the
  `UnaryTypeTrait` requirements with a base characteristic of
  `integral_constant<size_t, N>` for some `N`.

  <pre></code>
  
  template&lt;class T&gt; class variant_size&lt;const T&gt;;
  <del>template&lt;class T&gt; class variant_size&lt;volatile T&gt;;</del>
  <del>template&lt;class T&gt; class variant_size&lt;const volatile T&gt;;</del>
  
  </code></pre>

  Let `VS` denote `variant_size<T>` of the *cv*-unqualified type `T`. Then <del>each
  of the three templates</del><ins>the template</ins> shall satisfy the `UnaryTypeTrait` requirements with a
  base characteristic of `integral_constant<size_t, VS::value>`.

  <pre><code>
  template&lt;class... Types&gt;
    struct variant_size&lt;variant&lt;Types...&gt;&gt; : integral_constant&lt;size_t, sizeof...(Types)&gt; { };
  </code></pre>

  <pre><code>
  template&lt;size_t I, class T&gt; class variant_alternative&lt;I, const T&gt;;
  <del>template&lt;size_t I, class T&gt; class variant_alternative&lt;I, volatile T&gt;;</del>
  <del>template&lt;size_t I, class T&gt; class variant_alternative&lt;I, const volatile T&gt;;</del>
  </code></pre>

  Let `VA` denote `variant_alternative<I, T>` of the *cv*-unqualified type `T`.
  Then <del>each of the three templates</del><ins>the template</ins> shall meet the `TransformationTrait`
  requirements with a member typedef `type` that names the following type:<ins> `add_const_t<VA::type>`.</ins>
  
  <ul>
    <li>for the first specialization, `add_const_t<VA::type>`,
    <li>for the second specialization, `add_volatile_t<VA::type>`, and
    <li>for the third specialization, `add_cv_t<VA::type>`.
  </ul>

</blockquote>

Atomic operations library [**atomics**] {#atomics}
---------------------------------------

Modify as follows.

<blockquote>

  Operations on atomic types [**atomics.types.operations**]
  
  [ *Note:* Many operations are volatile-qualified. The "volatile as device
  register" semantics have not changed in the standard. This qualification means
  that volatility is preserved when applying these operations to volatile
  objects. It does not mean that operations on non-volatile objects become
  volatile. —*end note* ]

  [...]
  
  <pre><code>
  bool is_lock_free() const volatile noexcept;
  bool is_lock_free() const noexcept;
  </code></pre>

  *Returns:* `true` if the object's operations are lock-free, `false` otherwise.
  
  [ *Note:* The return value of the `is_lock_free` member function is consistent with the value of `is_always_lock_free` for the same type. —*end note* ]

  <pre><code>
  void store(T desired, memory_order order = memory_order::seq_cst) volatile noexcept;
  void store(T desired, memory_order order = memory_order::seq_cst) noexcept;
  </code></pre>

  *Requires:* The `order` argument shall not be `memory_order::consume`, `memory_order::acquire`, nor `memory_order::acq_rel`.

  *Effects:*  Atomically replaces the value pointed to by `this` with the value of `desired`. Memory is affected according to the value of `order`.
  
  <ins>*Remarks:* The `volatile` overload shall only participate in overload resolution when `atomic<T>::is_always:lock_free` is `true`.</ins>

  <pre><code>
  T operator=(T desired) volatile noexcept;
  T operator=(T desired) noexcept;
  </code></pre>

  *Effects:*  Equivalent to `store(desired)`.

  *Returns:* `desired`.

  <pre><code>
  T load(memory_order order = memory_order::seq_cst) const volatile noexcept;
  T load(memory_order order = memory_order::seq_cst) const noexcept;
  </code></pre>

  *Requires:* The `order` argument shall not be `memory_order::release` nor `memory_order::acq_rel`.

  *Effects:*  Memory is affected according to the value of `order`.

  *Returns:* Atomically returns the value pointed to by `this`.
  
  <ins>*Remarks:* The `volatile` overload shall only participate in overload resolution when `atomic<T>::is_always:lock_free` is `true`.</ins>

  <pre><code>
  operator T() const volatile noexcept;
  operator T() const noexcept;
  </code></pre>

  *Effects:*  Equivalent to: `return load();`

  <pre><code>
  T exchange(T desired, memory_order order = memory_order::seq_cst) volatile noexcept;
  T exchange(T desired, memory_order order = memory_order::seq_cst) noexcept;
  </code></pre>

  *Effects:*  Atomically replaces the value pointed to by `this` with `desired`. Memory is affected according to the value of `order`. These operations are atomic read-modify-write operations.

  *Returns:* Atomically returns the value pointed to by `this` immediately before the effects.

  <ins>*Remarks:* The `volatile` overload shall only participate in overload resolution when `atomic<T>::is_always:lock_free` is `true`.</ins>

  <pre><code>
  bool compare_exchange_weak(T& expected, T desired,
                             memory_order success, memory_order failure) volatile noexcept;
  bool compare_exchange_weak(T& expected, T desired,
                             memory_order success, memory_order failure) noexcept;
  bool compare_exchange_strong(T& expected, T desired,
                               memory_order success, memory_order failure) volatile noexcept;
  bool compare_exchange_strong(T& expected, T desired,
                               memory_order success, memory_order failure) noexcept;
  bool compare_exchange_weak(T& expected, T desired,
                             memory_order order = memory_order::seq_cst) volatile noexcept;
  bool compare_exchange_weak(T& expected, T desired,
                             memory_order order = memory_order::seq_cst) noexcept;
  bool compare_exchange_strong(T& expected, T desired,
                               memory_order order = memory_order::seq_cst) volatile noexcept;
  bool compare_exchange_strong(T& expected, T desired,
                               memory_order order = memory_order::seq_cst) noexcept;
  </code></pre>

  *Requires:* The `failure` argument shall not be `memory_order::release` nor `memory_order::acq_rel`.

  *Effects:*  Retrieves the value in `expected`. It then atomically compares the value representation of the value pointed to by `this` for equality with that previously retrieved from `expected`,eand if true, replaces the value pointed to by `this` with that in `desired`. If and only if the comparison is true, memory is affected according to the value of `success`, and if the comparison is false, memory is affected according to the value of `failure`. When only one `memory_order` argument is supplied, the value of `success` is `order`, and the value of `failure` is `order` except that a value of `memory_order::acq_rel` shall be replaced by the value `memory_order::acquire` and a value of `memory_order::release` shall be replaced by the value `memory_order::relaxed`. If and only if the comparison is false then, after the atomic operation, the value in `expected` is replaced by the value pointed to by `this` during the atomic comparison. If the operation returns `true`, these operations are atomic read-modify-write operations on the memory pointed to by `this`. Otherwise, these operations are atomic load operations on that memory.

  *Returns:* The result of the comparison.

  <ins>*Remarks:* The `volatile` overloads shall only participate in overload resolution when `atomic<T>::is_always:lock_free` is `true`.</ins>

  [...]
  
  Specializations for integers [**atomics.types.int**]
  
  <pre><code>
  T fetch_<i>key</i>(T operand, memory_order order = memory_order::seq_cst) volatile noexcept;
  T fetch_<i>key</i>(T operand, memory_order order = memory_order::seq_cst) noexcept;
  </code></pre>

  *Effects:* Atomically replaces the value pointed to by `this` with the result of the computation applied to the value pointed to by `this` and the given `operand`. Memory is affected according to the value of `order`. These operations are atomic read-modify-write operations.

  *Returns:* Atomically, the value pointed to by `this` immediately before the effects.

  <ins>*Remarks:* The `volatile` overloads shall only participate in overload resolution when `atomic<T>::is_always:lock_free` is `true`.</ins>

  *Remarks:* For signed integer types, the result is as if the object value and parameters were converted to their corresponding unsigned types, the computation performed on those types, and the result converted back to the signed type. [ *Note:* There are no undefined results arising from the computation.  —*end note* ]

  <pre><code>
  T operator <i>op</i>=(T operand) volatile noexcept;
  T operator <i>op</i>=(T operand) noexcept;
  </code></pre>

  *Effects:* Equivalent to: <code>return fetch_<i>key</i>(operand) <i>op</i> operand;</code>

  <ins>*Remarks:* The `volatile` overloads shall only participate in overload resolution when `atomic<T>::is_always:lock_free` is `true`.</ins>

  Specializations for floating-point types [**atomics.types.float**]

  The following operations perform arithmetic addition and subtraction computations. The key, operator, and computation correspondence are identified in [**atomic.arithmetic.computations**].

  <pre><code>
  T A::fetch_<i>key</i>(T operand, memory_order order = memory_order_seq_cst) volatile noexcept;
  T A::fetch_<i>key</i>(T operand, memory_order order = memory_order_seq_cst) noexcept;
  </code></pre>

  *Effects:* Atomically replaces the value pointed to by `this` with the result of the computation applied to the value pointed to by `this` and the given `operand`. Memory is affected according to the value of `order`. These operations are atomic read-modify-write operations.

  *Returns:* Atomically, the value pointed to by `this` immediately before the effects.

  <ins>*Remarks:* The `volatile` overloads shall only participate in overload resolution when `atomic<T>::is_always:lock_free` is `true`.</ins>

  *Remarks:* If the result is not a representable value for its type the result is unspecified, but the operations otherwise have no undefined behavior. Atomic arithmetic operations on <code><i>floating-point</i></code> should conform to the <code>std::numeric_limits&lt;<i>floating-point</i>&gt;</code> traits associated with the floating-point type. The floating-point environment for atomic arithmetic operations on <code><i>floating-point</i></code> may be different than the calling thread's floating-point environment.

  <pre><code>
  T operator <i>op</i>=(T operand) volatile noexcept;
  T operator <i>op</i>=(T operand) noexcept;
  </code></pre>

  *Effects:* Equivalent to: <code>return fetch_<i>key</i>(operand) <i>op</i> operand;</code>

  *Remarks:* If the result is not a representable value for its type the result is unspecified, but the operations otherwise have no undefined behavior. Atomic arithmetic operations on <code><i>floating-point</i></code> should conform to the <code>std::numeric_limits&lt;<i>floating-point</i>&gt;</code> traits associated with the floating-point type. The floating-point environment for atomic arithmetic operations on <code><i>floating-point</i></code> may be different than the calling thread's floating-point environment.

  Partial specialization for pointers [**atomics.types.pointer**]

  <pre><code>
  T* fetch_<i>key</i>(ptrdiff_t operand, memory_order order = memory_order::seq_cst) volatile noexcept;
  T* fetch_<i>key</i>(ptrdiff_t operand, memory_order order = memory_order::seq_cst) noexcept;
  </code></pre>

  *Requires:* T shall be an object type, otherwise the program is ill-formed. [ *Note:* Pointer arithmetic on \tcode{void*} or function pointers is ill-formed. —*end note* ]

  *Effects:* Atomically replaces the value pointed to by `this` with the result of the computation applied to the value pointed to by `this` and the given `operand`. Memory is affected according to the value of `order`. These operations are atomic read-modify-write operations.

  *Returns:* Atomically, the value pointed to by `this` immediately before the effects.

  <ins>*Remarks:* The `volatile` overloads shall only participate in overload resolution when `atomic<T>::is_always:lock_free` is `true`.</ins>

  *Remarks:* The result may be an undefined address, but the operations otherwise have no undefined behavior.

  <pre><code>
  T* operator <i>op</i>=(ptrdiff_t operand) volatile noexcept;
  T* operator <i>op</i>=(ptrdiff_t operand) noexcept;
  </code></pre>

  *Effects:* Equivalent to: <code>return fetch_<i>key</i>(operand) <i>op</i> operand;</code>

  Member operators common to integers and pointers to objects [**atomics.types.memop**]

  <pre><code>
  T operator++(int) volatile noexcept;
  T operator++(int) noexcept;
  </code></pre>

  *Effects:* Equivalent to: `return fetch_add(1);`

  <pre><code>
  T operator--(int) volatile noexcept;
  T operator--(int) noexcept;
  </code></pre>

  *Effects:* Equivalent to: `return fetch_sub(1);`

  <pre><code>
  T operator++() volatile noexcept;
  T operator++() noexcept;
  </code></pre>

  *Effects:* Equivalent to: `return fetch_add(1) + 1;`

  <pre><code>
  T operator--() volatile noexcept;
  T operator--() noexcept;
  </code></pre>

  *Effects:* Equivalent to: `return fetch_sub(1) - 1;`

  Non-member functions [**atomics.nonmembers**]

  A non-member function template whose name matches the pattern <code>atomic_<i>f</i></code> or the pattern <code>atomic_<i>f</i>_explicit</code> invokes the member function <code><i>f</i></code>, with the value of the first parameter as the object expression and the values of the remaining parameters (if any) as the arguments of the member function call, in order. An argument for a parameter of type `atomic<T>::value_type*` is dereferenced when passed to the member function call. If no such member function exists, the program is ill-formed.

  <pre><code>
  template&lt;class T&gt;
    void atomic_init(volatile atomic&lt;T&gt;* object, typename atomic&lt;T&gt;::value_type desired) noexcept;
  template&lt;class T&gt;
    void atomic_init(atomic&lt;T&gt;* object, typename atomic&lt;T&gt;::value_type desired) noexcept;
  </code></pre>

  *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* ]

  <ins>*Remarks:* The `volatile` overloads shall only participate in overload resolution when `atomic<T>::is_always:lock_free` is `true`.</ins>

  [ *Note:* The non-member functions enable programmers to write code that can be compiled as either C or C++, for example in a shared header file.  —*end note* ]


</blockquote>

Annex D {#annexD}
-------

All deletions above should be added to Annex D, such that `volatile` is now
deprecated in these use cases.


<pre class=biblio>
{
    "P1382R0": {
        "href": "http://wg21.link/P1382R0",
        "title": "volatile_load<T> and volatile_store<T>",
        "authors": ["Paul Mckenney", "JF Bastien"]
    }
}
</pre>
