-
Notifications
You must be signed in to change notification settings - Fork 17
/
P1152R4.bs
772 lines (600 loc) · 30 KB
/
P1152R4.bs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
<pre class='metadata'>
Title: Deprecating <code>volatile</code>
Shortname: P1152
Revision: 4
Audience: CWG
Status: P
Group: WG21
URL: http://wg21.link/P1152R4
!Source: <a href="https://github.com/jfbastien/papers/blob/master/source/P1152R4.bs">github.com/jfbastien/papers/blob/master/source/P1152R4.bs</a>
Editor: JF Bastien, Apple, jfbastien@apple.com
No abstract: true
Date: 2019-07-19
Markup Shorthands: markdown yes
</pre>
<style>
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="https://wg21.link/P1152R0#over">Overview</a>
* <a href="https://wg21.link/P1152R0#where">How we got here</a>
* <a href="https://wg21.link/P1152R0#why">Why the proposed changes?</a>
* <a href="https://wg21.link/P1152R0#examples">Examples</a>
See [[P1382R0]] for the follow-up paper on `volatile_load<T>` /
`volatile_store<T>` requested by SG1.
In Cologne, CWG was able to review this paper but LWG was not. The library parts
of this paper have therefore moved to [[P1831R0]] so that the language changes
can make C++20, and the library changes can be added to C++20 later.
Edit History {#edit}
============
r3 → r4 {#r3r4}
-------
Edit wording of the following sections as suggested by Jens Maurer:
[**expr.post.incr**], [**expr.pre.incr**], [**expr.ass**], [**dcl.fct**],
[**over.load**], [**over.built**].
Drop one word from [**tuple**] as suggested by Arthur O'Dwyer.
Add [**dcl.struct.bind**].
Add Annex D.
Move library parts to [[P1831R0]].
r2 → r3 {#r2r3}
-------
[[P1152R2]] was reviewed offline by Alisdair Meredith.
* `is_volatile<T>` should have been `is_volatile_v<T>`.
* Use *Mandates* instead of *Constraints* to allow marking a function as deleted or employing a `static_assert` instead of using `enable_if` or `requires`. This likely provides better error messages.
* "`is_volatile_v<T>` is `false`" was erroneously used instead of testing whether the `this` pointer itself was `volatile`. Wording of the *Mandates* clause was updated to only apply to the `volatile` overloads of methods instead.
r1 → r2 {#r1r2}
-------
[[P1152R1]] was seen by SG1 and EWG in Kona. This update does the following:
* Also edit sections [**expr.post.incr**], [**expr.pre.incr**], [**expr.ass**], which are redundant with other sections already modified by this paper.
* Change *Remarks* to *Constraints* per [[P1369R0]].
* Change language wording to explicitly call out deprecation.
<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>Forward this paper—with edits as discussed—to EWG for C++20.</th>
<th>SG1</th><th>3</th><th>12</th><th>1</th><th>1</th><th>0</th><th>✅</th>
</tr>
<tr>
<th>Proposal as presented for C++20.</th>
<th>EWG</th><th>6</th><th>27</th><th>1</th><th>0</th><th>0</th><th>✅</th>
</tr>
</table>
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}
=======
The proposed wording follows the language and library approach to deprecation:
* Language deprecation is called out in the Standard text itself, and repeated
in Annex D.
* Library deprecation presents the library without the deprecated feature, and
only mentions said feature in Annex D.
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>
Increment and decrement [**expr.post.incr**] {#expr.post.incr}
--------------------------------------------
Modify as follows.
<blockquote>
The value of a postfix `++` expression is the value of its operand. [ *Note:*
The value obtained is a copy of the original value —*end note* ] The operand
shall be a modifiable lvalue. The type of the operand shall be an
arithmetic type other than *cv* `bool`, or a
pointer to a complete object type. <ins>An operand with `volatile`-qualified
type is deprecated; see [**depr.volatile.type**].</ins> The value of the operand object is
modified by adding `1` to it. The value computation of the `++` expression is
sequenced before the modification of the operand object. With respect to an
indeterminately-sequenced function call, the operation of postfix `++` is a
single evaluation. [ *Note:* Therefore, a function call shall not intervene
between the lvalue-to-rvalue conversion and the side effect associated with
any single postfix `++` operator. —*end note* ] The result is a prvalue. The
type of the result is the *cv*-unqualified version of the type of the operand.
If the operand is a bit-field that cannot represent the incremented value, the
resulting value of the bit-field is implementation-defined. See also
[**expr.add**] and [**expr.ass**].
The operand of postfix `--` is decremented analogously to the postfix `++`
operator. [ *Note:* For prefix increment and decrement, see
[**expr.pre.incr**]. —*end note* ]
</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>
Increment and decrement [**expr.pre.incr**] {#expr.pre.incr}
-------------------------------------------
Modify as follows.
<blockquote>
The operand of prefix `++` is modified by adding `1`. The operand shall be a
modifiable lvalue. The type of the operand shall be an arithmetic type
other than *cv* `bool`, or a pointer to a
completely-defined object type. <ins>An operand with `volatile`-qualified type
is deprecated; see [**depr.volatile.type**].</ins> The result is the updated operand; it is an
lvalue, and it is a bit-field if the operand is a bit-field. The expression
`++x` is equivalent to `x+=1`. [ *Note:* See the discussions of [**expr.add**]
and assignment operators [**expr.ass**] for information on conversions. —*end
note* ]
The operand of prefix `--` is modified by subtracting `1`. The requirements on
the operand of prefix `--` and the properties of its result are otherwise the
same as those of prefix `++`. [ *Note:* For postfix increment and decrement,
see [**expr.post.incr**]. —*end note* ]
</blockquote>
Assignment and compound assignment operators [**expr.ass**] {#expr.ass}
-----------------------------------------------------------
Modify as follows.
<blockquote>
<ol>
<li>
The assignment operator (`=`) and the compound assignment operators all group
right-to-left.
</li>
<li>
All require a modifiable lvalue as their left operand; their result is an
lvalue referring to the left operand. The result in all cases is a bit-field
if the left operand is a bit-field. In all cases, the assignment is sequenced
after the value computation of the right and left operands, and before the
value computation of the assignment expression. The right operand is sequenced
before the left operand. With respect to an indeterminately-sequenced function
call, the operation of a compound assignment is a single evaluation. [ *Note:*
Therefore, a function call shall not intervene between the lvalue-to-rvalue
conversion and the side effect associated with any single compound assignment
operator. —*end note* ]
<pre>
<em>assignment-expression</em>
<em>conditional-expression</em>
<em>logical-or-expression assignment-operator initializer-clause</em>
<em>throw-expression</em>
<em>assignment-operator</em>: one of
<code>= *= /= %= += -= >>= <<= &= ^= |=</code>
</pre>
</li>
<li>
In simple assignment (`=`), the object referred to by the left operand is
modified by replacing its value with the result of the right operand.
</li>
<li>
If the left operand is not of class type, the expression is implicitly
converted to the cv-unqualified type of the left operand.
</li>
<li>
If the left operand is of class type, the class shall be complete. Assignment
to objects of a class is defined by the copy/move assignment.
</li>
<li>
[ *Note:* For class objects, assignment is not in general the same as
initialization. —*end note* ]
</li>
<li>
When the left operand of an assignment operator is a bit-field that cannot
represent the value of the expression, the resulting value of the bit-field is
implementation-defined.
</li>
<li><ins>
Simple assignments where the left operand is a `volatile`-qualified type that
is not of class type are deprecated (see [**depr.volatile.type**]) unless they are
either a discarded-value expression or appear in an unevaluated context.
</ins></li>
<li>
The behavior of an expression of the form
<code>E1 <em>op</em>= E2</code> is equivalent to
<code>E1 = E1 <em>op</em> E2</code>
except that `E1` is evaluated only once. <ins>Such expressions are deprecated
if `E1` has `volatile`-qualified type;
see [**depr.volatile.type**].</ins> In `+=` and `-=`, `E1` shall either
have arithmetic type or be a pointer to a possibly cv-qualified
completely-defined object type. In all other cases, `E1` shall have arithmetic
type.
</li>
<li>
If the value being stored in an object is read via another object that
overlaps in any way the storage of the first object, then the overlap shall be
exact and the two objects shall have the same type, otherwise the behavior is
undefined. [ *Note:* This restriction applies to the relationship between the
left and right sides of the assignment operation; it is not a statement about
how the target of the assignment may be aliased in general.
See [**basic.lval**]. —*end note* ]
</li>
<li>
A *braced-init-list* may appear on the right-hand side of
<ol>
<li>an assignment to a scalar, in which case the initializer list shall have at most a single element. The meaning of `x = {v}`, where `T` is the scalar type of the expression `x`, is that of `x = T{v}`. The meaning of `x = {}` is `x = T{}`.
<li>an assignment to an object of class type, in which case the initializer list is passed as the argument to the assignment operator function selected by overload resolution.
</ol>
</li>
</ol>
</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 with
`volatile`-qualified type is deprecated; see [**depr.volatile.type**].</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>A `volatile`-qualified return type is
deprecated; see [**depr.volatile.type**].</ins>
</blockquote>
Structured binding declarations [**dcl.struct.bind**] {#dcl.struct.bind}
-----------------------------------------------------
Modify as follows:
<blockquote>
A structured binding declaration introduces the *identifier*s
<code>v<sub>0</sub></code>, <code>v<sub>1</sub></code>,
<code>v<sub>2</sub></code>, ... of the *identifier-list* as names of *structured
binding*s. Let *cv* denote the *cv-qualifier*s in the *decl-specifier-seq* and
*S* consist of the *storage-class-specifier*s of the *decl-specifier-seq* (if
any). <ins>A *cv* that includes `volatile` is deprecated; see
[**depr.volatile.type**].</ins> First, a variable with a unique name `e` is
introduced. If the *assignment-expression* in the *initializer* has array type
`A` and no *ref-qualifier* is present, `e` is defined by
*attribute-specifier-seq*<sub>*opt*</sub> *S* *cv* `A` `e` `;`
</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}
-----------------------------------------
No changes since [**dcl.fct**] already handles deprecation.
<blockquote>
Parameter declarations that differ only in the presence or absence of
`const` and/or `volatile` are equivalent. That is, the
`const` and `volatile` 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}
-----------------------------------
No changes since [**expr.post.incr**], [**expr.pre.incr**], and [**expr.ass**]
already handle deprecation.
<blockquote>
In the remainder of this section, *vq* represents either `volatile` or no
cv-qualifier.
For every pair (*T*, *vq*), where *T* is an arithmetic type other than `bool`,
there exist candidate operator functions of the form
<pre><code>
vq T & operator++(vq T &);
T operator++(vq T &, int);
</code></pre>
For every pair (*T*, *vq*), where *T* is an arithmetic type other than `bool`,
there exist candidate operator functions of the form
<pre><code>
vq T & operator--(vq T &);
T operator--(vq T &, int);
</code></pre>
For every pair (*T*, *vq*), where *T* is a cv-qualified or cv-unqualified
object type, there exist candidate operator functions of the form
<pre><code>
T*vq& operator++(T*vq&);
T*vq& operator--(T*vq&);
T* operator++(T*vq&, int);
T* operator--(T*vq&, 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>
<em>cv12</em> T& operator->*(<em>cv1</em> C1*, <em>cv2</em> T C2::*);
</code></pre>
For every triple (*L*, *vq*, *R*), where *L* is an arithmetic type, and *R* is
a promoted arithmetic type, there exist candidate operator functions of the
form
<pre><code>
vq L& operator=(vq L&, R);
vq L& operator*=(vq L&, R);
vq L& operator/=(vq L&, R);
vq L& operator+=(vq L&, R);
vq L& operator-=(vq L&, R);
</code></pre>
For every pair (*T*, *vq*), where *T* is any type, there exist candidate
operator functions of the form
<pre><code>
T*vq& operator=(T*vq&, T*);
</code></pre>
For every pair (*T*, *vq*), where *T* is an enumeration or pointer to member
type, there exist candidate operator functions of the form
<pre><code>
vq T& operator=(vq T&, T );
</code></pre>
For every pair (*T*, *vq*), where *T* is a cv-qualified or cv-unqualified
object type, there exist candidate operator functions of the form
<pre><code>
T*vq& operator+=(T*vq&, std::ptrdiff_t);
T*vq& operator-=(T*vq&, std::ptrdiff_t);
</code></pre>
For every triple (*L*, *vq*, *R*), where *L* is an integral type, and *R* is a
promoted integral type, there exist candidate operator functions of the form
<pre><code>
vq L& operator%=(vq L&, R);
vq L& operator<<=(vq L&, R);
vq L& operator>>=(vq L&, R);
vq L& operator&=(vq L&, R);
vq L& operator^=(vq L&, R);
vq L& operator|=(vq L&, R);
</code></pre>
</blockquote>
Annex D {#annexD}
-------
Add the following wording to Annex D:
### Deprecated `volatile` types [**depr.volatile.type**] ### {#depr.volatile.type}
Postfix `++` and `--` expressions ([**expr.post.incr**]) and prefix `++` and
`--` expressions ([**expr.pre.incr**]) of `volatile`-qualified arithmetic and
pointer types are deprecated.
Certain assignments where the left operand is a `volatile`-qualified non-class
type are deprecated; see [**expr.ass**].
A function type ([**dcl.fct**]) with a parameter with `volatile`-qualified type
or with a `volatile`-qualified return type is deprecated.
A structured binding ([**dcl.struct.bind**]) of a `volatile`-qualified type is
deprecated.
<pre class=biblio>
{
"P1831R0": {
"href": "https://wg21.link/P1831R0",
"title": "Deprecating volatile: library",
"authors": ["JF Bastien"],
"date": "19 July 2019"
}
}
</pre>