forked from cplusplus/draft
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathn4619.html
3679 lines (2519 loc) · 132 KB
/
n4619.html
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
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html><html><head><meta charset="utf-8"><style>html { font-size: 100%; overflow-y: scroll; -webkit-text-size-adjust: 100%; -ms-text-size-adjust: 100%; }
body{
color:#444;
font-family:Georgia, Palatino, 'Palatino Linotype', Times, 'Times New Roman',
"Hiragino Sans GB", "STXihei", "微软雅黑", serif;
font-size:12px;
line-height:1.5em;
background:#fefefe;
width: 45em;
margin: 10px auto;
padding: 1em;
outline: 1300px solid #FAFAFA;
}
a{ color: #0645ad; text-decoration:none;}
a:visited{ color: #0b0080; }
a:hover{ color: #06e; }
a:active{ color:#faa700; }
a:focus{ outline: thin dotted; }
a:hover, a:active{ outline: 0; }
span.backtick {
border:1px solid #EAEAEA;
border-radius:3px;
background:#F8F8F8;
padding:0 3px 0 3px;
}
::-moz-selection{background:rgba(255,255,0,0.3);color:#000}
::selection{background:rgba(255,255,0,0.3);color:#000}
a::-moz-selection{background:rgba(255,255,0,0.3);color:#0645ad}
a::selection{background:rgba(255,255,0,0.3);color:#0645ad}
p{
margin:1em 0;
}
img{
max-width:100%;
}
h1,h2,h3,h4,h5,h6{
font-weight:normal;
color:#111;
line-height:1em;
}
h4,h5,h6{ font-weight: bold; }
h1{ font-size:2.5em; }
h2{ font-size:2em; border-bottom:1px solid silver; padding-bottom: 5px; }
h3{ font-size:1.5em; }
h4{ font-size:1.2em; }
h5{ font-size:1em; }
h6{ font-size:0.9em; }
blockquote{
color:#666666;
margin:0;
padding-left: 3em;
border-left: 0.5em #EEE solid;
}
hr { display: block; height: 2px; border: 0; border-top: 1px solid #aaa;border-bottom: 1px solid #eee; margin: 1em 0; padding: 0; }
pre , code, kbd, samp {
color: #000;
font-family: monospace;
font-size: 0.88em;
border-radius:3px;
background-color: #F8F8F8;
border: 1px solid #CCC;
}
pre { white-space: pre; white-space: pre-wrap; word-wrap: break-word; padding: 5px 12px;}
pre code { border: 0px !important; padding: 0;}
code { padding: 0 3px 0 3px; }
b, strong { font-weight: bold; }
dfn { font-style: italic; }
ins { background: #ff9; color: #000; text-decoration: none; }
mark { background: #ff0; color: #000; font-style: italic; font-weight: bold; }
sub, sup { font-size: 75%; line-height: 0; position: relative; vertical-align: baseline; }
sup { top: -0.5em; }
sub { bottom: -0.25em; }
ul, ol { margin: 1em 0; padding: 0 0 0 2em; }
li p:last-child { margin:0 }
dd { margin: 0 0 0 2em; }
img { border: 0; -ms-interpolation-mode: bicubic; vertical-align: middle; }
table { border-collapse: collapse; border-spacing: 0; }
td { vertical-align: top; }
@media only screen and (min-width: 480px) {
body{font-size:14px;}
}
@media only screen and (min-width: 768px) {
body{font-size:16px;}
}
@media print {
* { background: transparent !important; color: black !important; filter:none !important; -ms-filter: none !important; }
body{font-size:12pt; max-width:100%; outline:none;}
a, a:visited { text-decoration: underline; }
hr { height: 1px; border:0; border-bottom:1px solid black; }
a[href]:after { content: " (" attr(href) ")"; }
abbr[title]:after { content: " (" attr(title) ")"; }
.ir a:after, a[href^="javascript:"]:after, a[href^="#"]:after { content: ""; }
pre, blockquote { border: 1px solid #999; padding-right: 1em; page-break-inside: avoid; }
tr, img { page-break-inside: avoid; }
img { max-width: 100% !important; }
@page :left { margin: 15mm 20mm 15mm 10mm; }
@page :right { margin: 15mm 10mm 15mm 20mm; }
p, h2, h3 { orphans: 3; widows: 3; }
h2, h3 { page-break-after: avoid; }
}
</style><title>N4619</title></head><body>
<h1>N4619 Editors' Report -- Working Draft, Standard for Programming Language C++</h1>
<p>2016-11-28 <br />
Richard Smith (editor) (Google Inc) <br />
Dawn Perchik (co-editor) (Embarcadero Technologies Inc) <br />
Thomas Köppe (co-editor) (Google DeepMind) <br />
<code><cxxeditor@gmail.com></code></p>
<h2>Acknowledgements</h2>
<p>Special thanks to
Jens Maurer and Alisdair Meredith
for performing many large-scale editorial cleanups across the standard.</p>
<p>Thanks to all those who have <a href="https://github.com/cplusplus/draft/wiki/How-to-submit-an-editorial-issue">submitted editorial
issues</a>
and to those who have provided pull requests with fixes.</p>
<h2>New papers</h2>
<ul>
<li>N4619 is this Editors' Report.</li>
<li><a href="http://wg21.link/n4618">N4618</a> is the current working draft. It replaces <a href="http://wg21.link/n4606">N4606</a>.</li>
</ul>
<h2>Motions incorporated into committee draft</h2>
<h3>Core working group motions</h3>
<p>CWG motion 1: <a href="http://wg21.link/p0519r0">Core issue resolutions</a> for 5 issues in "Ready" status applied, resolving 6 issues:</p>
<ul>
<li><a href="http://wg21.link/cwg1395">1395</a> Partial ordering of variadic templates reconsidered</li>
<li><a href="http://wg21.link/cwg1825">1825</a> Partial ordering between variadic and non-variadic function templates (no changes, resolved by 1395)</li>
<li><a href="http://wg21.link/cwg1961">1961</a> Potentially-concurrent actions within a signal handler</li>
<li><a href="http://wg21.link/cwg2143">2143</a> Value-dependency via injected-class-name</li>
<li><a href="http://wg21.link/cwg2155">2155</a> Defining classes and enumerations via <em>using-declaration</em>s</li>
<li><a href="http://wg21.link/cwg2271">2271</a> Aliasing <code>this</code></li>
</ul>
<p>CWG motion 2: <a href="http://wg21.link/p0520r0">Core issue resolutions</a> for 2 issues in "Tentatively Ready" status applied:</p>
<ul>
<li><a href="http://wg21.link/cwg2100">2100</a> Value-dependent address of static data member of class template</li>
<li><a href="http://wg21.link/cwg2094">2094</a> Trivial copy/move constructor for class with volatile member</li>
</ul>
<p>CWG motion 3: <a href="http://wg21.link/p0507r0">Core issue resolutions</a> for 1 issue applied:</p>
<ul>
<li><a href="http://wg21.link/cwg1343">1343</a> Sequencing of non-class initialization</li>
</ul>
<p>CWG motion 4: <a href="http://wg21.link/p0283r2">P0522R0 "Matching of template template-arguments excludes compatible templates"</a>, resolving 1 issue:</p>
<ul>
<li><a href="http://wg21.link/cwg150">150</a> Template template parameters and default arguments</li>
</ul>
<p>CWG motion 5: <a href="http://wg21.link/p0003r5">P0003R5 "Removing deprecated exception specifications"</a>, resolving 3 NB comments:</p>
<ul>
<li>See also LWG motion 20, which applies the same paper</li>
<li>US 18, US 70, GB 43: Adopt P0003R5 to remove dynamic exception specifications</li>
</ul>
<p>CWG motion 6: <a href="http://wg21.link/p0490r0">P0490R0 "Core language changes addressing National Body comments for C++17 CD"</a>, resolving 1 issue and 19 NB comments:</p>
<ul>
<li>US 28: Incorrect definition for principal constructor</li>
<li>US 93: Argument evaluation order when calling an operator function</li>
<li>US 94, GB 13, FI 21: Class template deduction in explicit type conversion using a <em>braced-init-list</em></li>
<li>US 103: Explicit deduction guides consider default template arguments</li>
<li>GB 5: Definition of template parameter</li>
<li>GB 6: Definition of undefined behavior vs constexpr</li>
<li>GB 19: Missing cv-qualification when materializing a temporary object</li>
<li>GB 20: Decomposition declaration should commit to tuple interpretation early</li>
<li>GB 23: Handlers taking a reference to array or function</li>
<li>GB 25: Imprecise description when <code>terminate</code> is called</li>
<li>GB 26: 'Last' active handler and multithreading</li>
<li>GB 27: Multiple activations of the same exception object</li>
<li>GB 63: Add limit for number of lambda captures</li>
<li>GB 64: Add limit for length of <em>initializer-list</em></li>
<li>GB 65: Add limit for number of <em>identifier</em>s in decomposition declaration</li>
<li>FI 20: Decomposition declarations with parentheses</li>
<li>RU 1, <a href="http://wg21.link/cwg253">253</a>: Why must empty or fully-initialized const objects be initialized?</li>
</ul>
<p>CWG motion 7: <a href="http://wg21.link/p0195r2">P0195R2 "Pack expansions in <em>using-declaration</em>s"</a></p>
<p>CWG motion 8: <a href="http://wg21.link/p0512r0">P0512R0 "Class template argument deduction NB comments"</a></p>
<ul>
<li>US 19: Give explicit deduction guides priority over implicit deduction guides</li>
<li>US 20: <code>T&&</code> in an implicit deduction guide is not always a forwarding reference</li>
</ul>
<p>CWG motion 9 was not approved.</p>
<p>CWG motion 10 applies to the Modules TS</p>
<p>CWG motion 11 applies to the Concepts TS</p>
<p>Core motions added a total of 1 page to Clause 1-16.</p>
<h3>Library working group motions</h3>
<p>LWG motions 1-3 apply to the Library Fundamentals (v2) TS</p>
<p>LWG motions 4-5 apply to the Ranges TS</p>
<p>LWG motions 6-7 apply to the Networking TS</p>
<p>LWG motions 8-9 apply to the Coroutines TS</p>
<p>LWG motion 10: <a href="http://wg21.link/p0304r1">Library issue resolutions</a> for 1 issues in "Immediate" status applied:</p>
<ul>
<li><a href="http://wg21.link/lwg2770">2770</a> <code>tuple_size<const T></code> specialization breaks decomposition declarations</li>
</ul>
<p>LWG motion 11: <a href="http://wg21.link/p0165r3">Library issue resolutions</a> for 64 issues in "Tentatively Ready" status applied:</p>
<ul>
<li><a href="http://wg21.link/lwg2062">2062</a> Effect contradictions w/o no-throw guarantee of <code>std::function</code> swaps</li>
<li><a href="http://wg21.link/lwg2166">2166</a> Heap property underspecified?</li>
<li><a href="http://wg21.link/lwg2221">2221</a> No formatted output operator for <code>nullptr</code></li>
<li><a href="http://wg21.link/lwg2223">2223</a> <code>shrink_to_fit</code> effect on iterator validity</li>
<li><a href="http://wg21.link/lwg2261">2261</a> Are containers required to use their <code>pointer</code> type internally?</li>
<li><a href="http://wg21.link/lwg2394">2394</a> <code>locale::name</code> specification unclear — what is implementation-defined?</li>
<li><a href="http://wg21.link/lwg2460">2460</a> LWG issue 2408 and value categories</li>
<li><a href="http://wg21.link/lwg2468">2468</a> Self-move-assignment of library types</li>
<li><a href="http://wg21.link/lwg2475">2475</a> Allow overwriting of <code>std::basic_string</code> terminator with <code>charT()</code> to allow cleaner interoperation with legacy APIs</li>
<li><a href="http://wg21.link/lwg2503">2503</a> <code>multiline</code> option should be added to <code>syntax_option_type</code></li>
<li><a href="http://wg21.link/lwg2510">2510</a> Tag types should not be <code>DefaultConstructible</code></li>
<li><a href="http://wg21.link/lwg2514">2514</a> Type traits must not be <code>final</code></li>
<li><a href="http://wg21.link/lwg2519">2519</a> Iterator <code>operator-=</code> has gratuitous undefined behaviour</li>
<li><a href="http://wg21.link/lwg2531">2531</a> <code>future::get</code> should explicitly state that the shared state is released</li>
<li><a href="http://wg21.link/lwg2534">2534</a> Constrain rvalue stream operators <strong>(with normative changes, see below)</strong></li>
<li><a href="http://wg21.link/lwg2536">2536</a> What should <code><complex.h></code> do?</li>
<li><a href="http://wg21.link/lwg2540">2540</a> <code>unordered_multimap::insert</code> hint iterator</li>
<li><strong><a href="http://wg21.link/lwg2543">2543</a> not applied, see below</strong></li>
<li><a href="http://wg21.link/lwg2544">2544</a> <code>istreambuf_iterator(basic_streambuf<charT, traits>* s)</code> effects unclear when <code>s</code> is <code>0</code></li>
<li><a href="http://wg21.link/lwg2556">2556</a> Wide contract for <code>future::share()</code></li>
<li><a href="http://wg21.link/lwg2562">2562</a> Consistent total ordering of pointers by comparison functors</li>
<li><a href="http://wg21.link/lwg2567">2567</a> Specification of logical operator traits uses <code>BaseCharacteristic</code>, which is defined only for <code>UnaryTypeTraits</code> and <code>BinaryTypeTraits</code></li>
<li><a href="http://wg21.link/lwg2569">2569</a> <code>conjunction</code> and <code>disjunction</code> requirements are too strict</li>
<li><a href="http://wg21.link/lwg2578">2578</a> Iterator requirements should reference iterator traits</li>
<li><a href="http://wg21.link/lwg2584">2584</a> <code><regex></code> ECMAScript <code>IdentityEscape</code> is ambiguous</li>
<li><a href="http://wg21.link/lwg2589">2589</a> <code>match_results</code> can't satisfy the requirements of a container</li>
<li><a href="http://wg21.link/lwg2591">2591</a> <code>std::function</code>'s member template <code>target()</code> should not lead to undefined behaviour</li>
<li><a href="http://wg21.link/lwg2598">2598</a> <code>addressof</code> works on temporaries</li>
<li><a href="http://wg21.link/lwg2664">2664</a> <code>operator/</code> (and other append) semantics not useful if argument has root</li>
<li><a href="http://wg21.link/lwg2672">2672</a> Should <code>is_empty</code> use <code>error_code</code> in its specification?</li>
<li><a href="http://wg21.link/lwg2678">2678</a> <code>std::filesystem</code> <code>enum class</code>es overspecified</li>
<li><a href="http://wg21.link/lwg2679">2679</a> Inconsistent use of "<em>Effects:</em> Equivalent to"</li>
<li><a href="http://wg21.link/lwg2680">2680</a> Add "Equivalent to" to filesystem</li>
<li><a href="http://wg21.link/lwg2681">2681</a> <code>filesystem::copy()</code> cannot copy symlinks</li>
<li><a href="http://wg21.link/lwg2686">2686</a> Why is <code>std::hash</code> specialized for <code>error_code</code>, but not <code>error_condition</code>?</li>
<li><a href="http://wg21.link/lwg2694">2694</a> Application of LWG 436 accidentally deleted definition of "facet"</li>
<li><a href="http://wg21.link/lwg2696">2696</a> Interaction between <code>make_shared</code> and <code>enable_shared_from_this</code> is underspecified</li>
<li><a href="http://wg21.link/lwg2699">2699</a> Missing restriction in [numeric.requirements]</li>
<li><a href="http://wg21.link/lwg2712">2712</a> <code>copy_file(from, to, ...)</code> has a number of unspecified error conditions</li>
<li><a href="http://wg21.link/lwg2722">2722</a> <code>equivalent</code> incorrectly specifies throws clause</li>
<li><a href="http://wg21.link/lwg2729">2729</a> Missing SFINAE on <code>std::pair::operator=</code></li>
<li><a href="http://wg21.link/lwg2732">2732</a> Questionable specification of <code>path::operator/=</code> and <code>path::append</code></li>
<li><a href="http://wg21.link/lwg2735">2735</a> <code>std::abs(short)</code>, <code>std::abs(signed char)</code> and others should return <code>int</code> instead of <code>double</code> in order to be compatible with C++98 and C</li>
<li><a href="http://wg21.link/lwg2736">2736</a> <code>nullopt_t</code> insufficiently constrained</li>
<li><a href="http://wg21.link/lwg2738">2738</a> <code>is_constructible</code> with <code>void</code> types</li>
<li><a href="http://wg21.link/lwg2739">2739</a> Issue with <code>time_point</code> non-member subtraction with an <code>unsigned</code> duration</li>
<li><a href="http://wg21.link/lwg2740">2740</a> <code>constexpr optional<T>::operator-></code></li>
<li><a href="http://wg21.link/lwg2742">2742</a> Inconsistent <code>string</code> interface taking <code>string_view</code></li>
<li><a href="http://wg21.link/lwg2744">2744</a> <code>any</code>'s <code>in_place</code> constructors</li>
<li><a href="http://wg21.link/lwg2747">2747</a> Possibly redundant <code>std::move</code> in [alg.foreach]</li>
<li><a href="http://wg21.link/lwg2748">2748</a> swappable traits for <code>optional</code>s</li>
<li><a href="http://wg21.link/lwg2749">2749</a> swappable traits for <code>variant</code>s</li>
<li><a href="http://wg21.link/lwg2752">2752</a> <em>Throws:</em> clauses of <code>async</code> and <code>packaged_task</code> are unimplementable</li>
<li><strong><a href="http://wg21.link/lwg2753">2753</a> not applied, see below</strong></li>
<li><a href="http://wg21.link/lwg2754">2754</a> The <code>in_place</code> constructors and <code>emplace</code> functions added by P0032R3 don't require <code>CopyConstructible</code></li>
<li><a href="http://wg21.link/lwg2755">2755</a> [string.view.io] uses non-existent <code>basic_string_view::to_string</code> function</li>
<li><a href="http://wg21.link/lwg2756">2756</a> <code>optional<T></code> should 'forward' <code>T</code>'s implicit conversions</li>
<li><a href="http://wg21.link/lwg2758">2758</a> <code>std::string{}.assign("ABCDE", 0, 1)</code> is ambiguous</li>
<li><a href="http://wg21.link/lwg2759">2759</a> <code>gcd</code> / <code>lcm</code> and <code>bool</code></li>
<li><a href="http://wg21.link/lwg2760">2760</a> non-<code>const</code> <code>basic_string::data</code> should not invalidate iterators</li>
<li><a href="http://wg21.link/lwg2765">2765</a> Did LWG 1123 go too far?</li>
<li><a href="http://wg21.link/lwg2767">2767</a> <code>not_fn</code> <code>call_wrapper</code> can form invalid types</li>
<li><a href="http://wg21.link/lwg2771">2771</a> Broken <em>Effects:</em> of some <code>basic_string::compare</code> functions in terms of <code>basic_string_view</code></li>
<li><a href="http://wg21.link/lwg2773">2773</a> Making <code>std::ignore</code> <code>constexpr</code></li>
<li><a href="http://wg21.link/lwg2777">2777</a> <code>basic_string_view::copy</code> should use <code>char_traits::copy</code></li>
<li><a href="http://wg21.link/lwg2778">2778</a> <code>basic_string_view</code> is missing <code>constexpr</code></li>
</ul>
<p>LWG motion 12: <a href="http://wg21.link/p0426r1">P0426R1 "<code>constexpr</code> for <code>std::char_traits</code>"</a>, resolving 2 NB comments:</p>
<ul>
<li>US 81, RU 4: <code>char_traits</code> operations should be <code>constexpr</code></li>
</ul>
<p>LWG motion 13: <a href="http://wg21.link/p0403r1">P0403R1 "Literal suffix for <code>basic_string_view</code>"</a>, resolving 2 NB comments:</p>
<ul>
<li>US 80, FI 6: Add user-defined literal suffix for <code>basic_string_view</code></li>
</ul>
<p>LWG motion 14: <a href="http://wg21.link/p0505r0">P0505R0 "<code>constexpr</code> for <code><chrono></code>"</a>, resolving 1 NB comment:</p>
<ul>
<li>GB 50: Make member functions of <code>duration</code> and <code>time_point</code> <code>constexpr</code></li>
</ul>
<p>LWG motion 15: <a href="http://wg21.link/p0418r2">P0418R2 "Fail or succeed: there is no atomic lattice"</a>, resolving 1 issue and 1 NB comment:</p>
<ul>
<li>CA 16: Merge P0418R1 or similar to resolve LWG 2445</li>
<li><a href="http://wg21.link/lwg2445">2445</a> "Stronger" memory ordering</li>
</ul>
<p>LWG motion 16: <a href="http://wg21.link/p0508r0">P0508R0 "Structured bindings for <em>node_handle</em>s"</a>, resolving 1 NB comment:</p>
<ul>
<li>GB 58: Allow decomposition of <code>insert_return_type</code></li>
</ul>
<p>LWG motion 17: <a href="http://wg21.link/p0503r0">P0503R0 "Correcting library usage of 'literal type'"</a>, resolving 3 NB comments:</p>
<ul>
<li>GB 68: Verify term "literal type" is used appropriately</li>
<li>US 154: Copy constructor of <code>istream_iterator</code> and literal types</li>
<li>US 155: Destructor of <code>istream_iterator</code> and literal types</li>
</ul>
<p>LWG motion 18: Two papers applied, resolving 1 NB comment:</p>
<ul>
<li><a href="http://wg21.link/p0414r2">P0414R2 "Merging <code>shared_ptr</code> changes from Library Fundamentals (v2) TS"</a></li>
<li><a href="http://wg21.link/p0497r0">P0497R0 "Fixes to <code>shared_ptr</code> support for arrays"</a></li>
<li>FI 19: Adopt P0414</li>
</ul>
<p>LWG motion 19: <a href="http://wg21.link/p0504r0">P0504R0 "Revisiting in-place tag types for <code>any</code>/<code>optional</code>/<code>variant</code>"</a>, resolving 1 NB comment:</p>
<ul>
<li>CH 3(a): <code>in_place</code> tags prevent perfect forwarding after decay to function</li>
</ul>
<p>LWG motion 20: <a href="http://wg21.link/p0003r5">P0003R5 "Removing deprecated exception specifications"</a>, resolving 3 NB comments:</p>
<ul>
<li>See also CWG motion 5, which applies the same paper</li>
<li>US 18, US 70, GB 43: Adopt P0003R5 to remove dynamic exception specifications</li>
</ul>
<p>LWG motion 21: <a href="http://wg21.link/p0510r0">P0510R0 "Disallowing references, incomplete types, arrays, and empty <code>variant</code>s"</a>, resolving 12 NB comments:</p>
<ul>
<li>US 112: Explicitly disallow <code>variant<></code></li>
<li>US 115, US 181, FI 22: Remove support for <code>variant<void, ...></code></li>
<li>US 116: Remove support for <code>variant<T[N], ...></code></li>
<li>US 117: Remove support for <code>variant<T(&)(), ...></code></li>
<li>US 120: Remove redundant wording for <code>void</code> elements in <code>variant</code></li>
<li>CH 3(b): Remove support for <code>variant<T&, ...></code></li>
<li>CH 4: Improve support for <code>variant<void, ...></code></li>
<li>CH 5: Repair <code>variant<></code></li>
<li>CH 6: Clarify behavior for <code>variant<T&, ...></code></li>
<li>CH 8: Clarify construction behavior for <code>variant<></code></li>
</ul>
<p>LWG motion 22: <a href="http://wg21.link/p0516r0">P0516R0 "Clarify that <code>shared_future</code>'s copy operations have wide contracts"</a>, resolving 1 NB comment:</p>
<ul>
<li>GB 62: Give <code>shared_future</code> copy operations a wide contract and <code>noexcept</code></li>
</ul>
<p>LWG motion 23: <a href="http://wg21.link/p0509r1">P0509R1 "Restrictions on exception handling"</a>, resolving 2 NB comments: <strong>see below</strong></p>
<ul>
<li>GB 41: Unclear restrictions on strengthening exception specifications</li>
<li>GB 42: Use of 'should' suggests unintended normative encouragement</li>
</ul>
<p>LWG motion 24: <a href="http://wg21.link/p0502r0">P0502R0 "Throwing out of a parallel algorithm terminates -- but how?"</a>, resolving 7 NB comments:</p>
<ul>
<li>US 15, US 167: Revisit calling <code>terminate</code> in response to an exception from a parallel algorithm</li>
<li>US 16, US 168: Clarify (nondeterministic?) behavior when rethrowing exception from element access function</li>
<li>US 169: Use an <code>exception_list</code> to propagate multiple exceptions from parallel algorithm execution</li>
<li>US 170: Allow for future addition of alternative exception handling mechanisms to parallel algorithms</li>
<li>CA 17: Preserve parallel algorithm exception behavior in CD</li>
</ul>
<p>LWG motion 25: <a href="http://wg21.link/p0517r0">P0517R0 "Make <code>future_error</code> constructible"</a>, resolving 1 NB comment:</p>
<ul>
<li>US 163: Document constructor for <code>future_error</code></li>
</ul>
<p>LWG motion 26: <a href="http://wg21.link/p0521r0">P0521R0 "<code>shared_ptr</code> <code>use_count</code>/<code>unique</code>"</a>, resolving 1 NB comment:</p>
<ul>
<li>CA 14: <code>use_count</code> needs either synchronization or weaker guarantees</li>
</ul>
<p>LWG motion 27: <a href="http://wg21.link/p0513r0">P0513R0 "Poisoning the hash"</a>, resolving 2 issues and 2 NB comment:</p>
<ul>
<li>FI 15: "Poison" <code>hash<optional<T>></code> if <code>T</code> is not hashable</li>
<li>GB 69: Reword requirements and remarks for <code>hash<variant<T...>></code> specialization</li>
<li><a href="http://wg21.link/lwg2791">2791</a> <code>string_view</code>s and <code>string</code>s should yield same hash values</li>
<li><a href="http://wg21.link/lwg2543">2543</a> <code>hash</code> support for <code>enum</code>s underspecified</li>
</ul>
<p>LWG motion 28: <a href="http://wg21.link/p0067r5">P0067R5 "Elementary string conversions"</a>, resolving 1 NB comment:</p>
<ul>
<li>FI 5: Merge fixed version of P0067</li>
</ul>
<p>LWG motion 29: <a href="http://wg21.link/p0435r1">P0435R1 "LWG issue resolutions for <code>common_type</code>"</a></p>
<p>Library motions added a total of 9 pages to Clause 17-30.</p>
<h2>Notable changes to papers as moved</h2>
<h3>LWG motion 11</h3>
<h4>LWG2534</h4>
<p>The wording change applied here needed to be rebased onto the wording change
applied by LWG2328 as part of 2016-06 LWG Motion 1.</p>
<p>LWG2328 changes the rvalue ostream extractor to use perfect forwarding, changing from:</p>
<blockquote>
<p><code>
template <class charT, class traits, class T> <br />
basic_istream<charT, traits>& <br />
operator>>(basic_istream<charT, traits>&& is, T& x);
</code></p>
<p>-1- <em>Effects:</em> <code>is >> x</code></p>
</blockquote>
<p>to:</p>
<blockquote>
<p><code>
template <class charT, class traits, class T> <br />
basic_istream<charT, traits>& <br />
operator>>(basic_istream<charT, traits>&& is, T&& x);
</code></p>
<p>-1- <em>Effects:</em> Equivalent to:
<code>
is >> std::forward<T>(x); <br />
return is;
</code></p>
</blockquote>
<p>LWG2534 adds a matching SFINAE condition, and proposes this wording based on
the standard prior to the application of LWG2328:</p>
<blockquote>
<p>-?- Remarks: This function shall not participate in overload resolution unless the expression <code>is >> x</code> is well-formed.</p>
</blockquote>
<p>The two LWG issue resolutions have been editorially merged, resulting instead
in the addition of this SFINAE condition:</p>
<blockquote>
<p>-?- Remarks: This function shall not participate in overload resolution unless the expression <code>is >> std::forward<T>(x)</code> is well-formed.</p>
</blockquote>
<h4>LWG2543</h4>
<p>The resolution of
<a href="http://wg21.link/lwg2543">LWG issue 2543</a>
is made redundant and unnecessary by
LWG motion 27 in
<a href="http://wg21.link/p0513r0">P0513R0</a>,
which applies a more general fix to the same wording.
As a result, LWG2543's resolution has not been applied,
and instead LWG2543 should be marked as resolved by P0513R0.</p>
<h4>LWG2753</h4>
<p>The resolution of
<a href="http://wg21.link/lwg2753">LWG issue 2753</a>
conflicts with the resolution of
<a href="http://wg21.link/lwg2756">LWG issue 2756</a>
and has not been applied.
In particular,
LWG 2753 changes the draft to say that the
<code>optional(const optional<T>&)</code> constructor
should not participate in overload resolution
if <code>!is_copy_constructible_v<T></code>, whereas
LWG 2756 changes the draft to say that the
constructor should be deleted in the same case.</p>
<h3>LWG motion 23</h3>
<p>The wording of this paper intended to apply on top of the wording changes applied by
<a href="http://wg21.link/p0003r5">P0003</a> (applied by CWG motion 5 and LWG motion 20),
but was not updated to match the latest wording changes from P0003R5, and as a
result, many of its proposed changes are redundant with those applied by P0003R5.
There is no conflict between the intent of the two papers, and both have
been applied.</p>
<h2>Disposition of editorial NB comments on C++ 2017 CD1</h2>
<p>Listed below are draft disposition for all comments that were
filed as editorial in the ISO 14882 CD (2016) NB comments,
<a href="http://wg21.link/p0488r0">p0488r0</a>,
and the late editorial comments in <a href="http://wg21.link/p0489r0">p0489r0</a>.
Except where otherwise noted, these dispositions only represent the current
viewpoint of the Project Editor.</p>
<h3>ES Comments</h3>
<p>ES 3: Accepted, fixed in f6482016.</p>
<ul>
<li>Example is correct with or without proposed change.</li>
</ul>
<h3>US Comments</h3>
<p>US 4: No consensus for change.</p>
<ul>
<li>While <code>_v</code> forms are generally preferred in library clauses, defining the core
language semantics in terms of a variable template seems to introduce undue
complexity.</li>
<li>CWG concurs with this direction.</li>
</ul>
<p>US 9: Accepted, fixed in 97058f9c.</p>
<ul>
<li>LWG concurs with this direction.</li>
</ul>
<p>US 11: Accepted with modifications, fixed in 663f1324.</p>
<ul>
<li>In the reference in paragraph 9, the <code>::value</code> was removed to match similar specifications.</li>
</ul>
<p>US 12: Accepted, fixed in 0fdcc1ab.</p>
<p>US 13: Accepted with modifications, fixed by 79974877.</p>
<ul>
<li><p>Specifying the value of <code>is_destructible_v<T></code> within the specification for
<code>is_destructible</code> would be considerably less clear than specifying the value
of <code>is_destructible<T>::value</code>.</p></li>
<li><p><strong>Modified resolution:</strong> Instead of proposed fix, change Condition for
<code>is_destructible</code> to:</p></li>
</ul>
<blockquote>
<p>Condition: Either <code>T</code> is a reference type, or <code>T</code> is a complete object type
for which the expression <code>declval<U&>().~U()</code> is well-formed when treated
as an unevaluated operand (Clause [expr]), where <code>U</code> is
<code>remove_all_extents_t<T></code>.</p>
</blockquote>
<ul>
<li>LWG concurs with this direction.</li>
</ul>
<p>US 26: Accepted, fixed by 85aac089.</p>
<p>US 27: Accepted, fixed by fb925656.</p>
<p>US 38: Accepted, fixed by adb0da05.</p>
<ul>
<li>LWG concurs with this direction.</li>
</ul>
<p>US 39: Accepted, fixed by d47d5ca4.</p>
<ul>
<li>LWG concurs with this direction. </li>
</ul>
<p>US 41: <strong>LWG to handle issue</strong></p>
<ul>
<li>LWG has deferred a decision on this to Kona.</li>
</ul>
<p>US 42: <strong>LWG to handle issue</strong></p>
<ul>
<li>The suggested resolution contradicts [fs.op.status]/7, which indicates that
pathname resolution does always resolve a symlink. There is no other
specification of how pathname resolution behaves, so the proposed note would
not be justified by normative text.</li>
<li><p>LWG has deferred a decision on this to Kona.</p>
<p>US 47: <strong>LWG to handle issue</strong></p></li>
<li><p>LWG has deferred a decision on this to Kona.</p></li>
</ul>
<p>US 50: <strong>LWG to handle issue</strong></p>
<ul>
<li>The proposed change seems valuable, but would be a normative change if the type
is an input iterator type for which <code>decay_t</code> would produce a different type.
The Project Editor would like LWG to consider whether that change is acceptable.</li>
<li>LWG has deferred a decision on this to Kona.</li>
</ul>
<p>US 87: <strong>SG1 to handle issue</strong></p>
<ul>
<li>CWG considers the revised term to be less clear. A compromise term "block with
progress guarantee delegation" (removing the "forward" but retaining the
"guarantee") has been proposed.</li>
</ul>
<p>US 88: Accepted, fixed in 554514cc.</p>
<p>US 89: Accepted with modifications, fixed in 7e920239, d580a0dd.</p>
<ul>
<li>"+" in section heading replaced by "and"</li>
</ul>
<p>US 90: Accepted, fixed in 131716c4.</p>
<p>US 91: Accepted, fixed in 0a344234.</p>
<ul>
<li>LWG and SG1 concur with the direction of this issue.</li>
</ul>
<p>US 96: Accepted, fixed in e6d9dfff.</p>
<p>US 97: Duplicate of US 4.</p>
<p>US 120: Accepted, fixed in a8f966f5.</p>
<ul>
<li>LWG concurs with this direction.</li>
</ul>
<p>US 133: Accepted, fixed in 71c347ed.</p>
<p>US 136: Accepted, fixed in 27b46764.</p>
<p>US 138: No consensus for change.</p>
<ul>
<li>[func.requires] are requirements on the library, [requirements] are
requirements on the program. [func.requires] does not fit within
[requirements], nor within Clause 17 at all.</li>
<li>The call wrapper terms are not used outside the specified clause (except within
Annex D), so moving them to [definitions] does not seem useful.</li>
</ul>
<p>US 149: No consensus for change.</p>
<ul>
<li>It is unclear what this comment is referencing. There is no note in 23.3.7.3
[array.special]/3, and 23.2.1 [container.requirements.general]/9 already
excludes <code>array</code> from its general requirements.</li>
<li>Perhaps the objection is that the semantics of <code>array::swap</code> are never actually
defined anywhere -- do we use <code>swap(a[i], b[i])</code> to swap elements, or some other
mechanism such as move-assigning via a temporary? -- in which case this omission
does not seem editorial.</li>
<li>LWG concurs with this direction.</li>
</ul>
<p>US 152: <strong>LWG to handle issue</strong></p>
<ul>
<li>This comment is not editorial.</li>
</ul>
<p>US 157: Duplicate of US 91.</p>
<p>US 158: No consensus for change.</p>
<ul>
<li>The Project Editor believes that including the description of the <code><numerics></code>
header in the "Algorithms" clause instead of the "Numerics" clause would harm
the organization of the standard.
One possible approach would be to rename the "Numerics" subclause to a name
that fits its remaining content, but LWG did not support that approach.</li>
<li>The last sentence of the proposed change for US 166 appears to be intended to
be part of this NB comment instead.</li>
<li>LWG concurs with this direction.</li>
</ul>
<p>US 173: Accepted, fixed in 4fde500c.</p>
<p>US 179: Accepted with modifications, fixed in 662ddc79.</p>
<ul>
<li>Renamed section label to
[optional.optional] since optional is not a class, matching [pairs.pair],
[tuple.tuple], [variant.variant].</li>
<li>LWG concurs with this direction.</li>
</ul>
<p>US 180: Accepted with modifications, fixed in e62da07d.</p>
<ul>
<li>Section label not changed (see US 179).</li>
<li>LWG concurs with this direction.</li>
</ul>
<p>US 182: Accepted, fixed by e229a482.</p>
<h3>GB Comments</h3>
<p>GB 7: Accepted, fixed in fd1204ed. </p>
<ul>
<li>CWG concurs with the direction of this issue.</li>
</ul>
<p>GB 8: Accepted, fixed in d0e5d065.</p>
<ul>
<li>CWG concurs with the direction of this issue.</li>
</ul>
<p>GB 11: Accepted, fixed by 4fa3ef43.</p>
<p>GB 14: Accepted, fixed by 142c82e4.</p>
<ul>
<li>Not filed as editorial, but will be handled editorially per CWG request.</li>
<li>CWG concurs with the direction of this issue.</li>
</ul>
<p>GB 22: Accepted, fixed by e11da84f.</p>
<ul>
<li>No type listed for comment, but considered editorial</li>
<li>CWG concurs with the direction of this issue.</li>
</ul>
<p>GB 24: Accepted, fixed by 84cb6529.</p>
<ul>
<li>CWG concurs with the direction of this issue.</li>
</ul>
<p>GB 29: Accepted, fixed in 6621ef71.</p>
<p>GB 31: Accepted with modifications, fixed in 32b2de88.</p>
<ul>
<li>The definition of "character traits" is in 21.2/1. The relevant traits classes
are actually only defined in Clause 21, and the headers in Clause 22 don't even
declare these traits classes (although they do use them). The note is
sufficiently wrong that the best solution appears to be to remove it entirely.</li>
<li>Removed note.</li>
</ul>
<p>GB 32: Accepted, fixed in 94244ddf.</p>
<p>GB 33: Accepted, fixed in a8d89234.</p>
<p>GB 34: Accepted, fixed in ddc64ff8.</p>
<p>GB 37: Accepted, fixed in a5e70c64.</p>
<ul>
<li>LWG concurs with this direction.</li>
</ul>
<p>GB 43: <strong>LWG to handle issue</strong></p>
<ul>
<li>Resolved by CWG motion 5 / LWG motion 20</li>
</ul>
<p>GB 47: <strong>LWG to handle issue</strong></p>
<ul>
<li>Resolved by LWG motion 18</li>
</ul>
<p>GB 48: Accepted, fixed in 2a96241e.</p>
<p>GB 52: Accepted, fixed in 65859b3b.</p>
<p>GB 66: <strong>CWG to handle issue</strong></p>
<p>GB 67: Accepted, fixed in 464156d1.</p>
<h3>RU Comments</h3>
<p>No editorial comments.</p>
<h3>JP Comments</h3>
<p>JP 1: Accepted with modifications, fixed by 942b3fbc.</p>
<ul>
<li>Additional changes:
<ol>
<li>[iostream.objects.overview]/4: add cross-reference to C11 7.21.2, and replace
"C standard" with "C standard library" for consistency</li>
<li>[alg.c.library]/2: replace "C standard" with "C standard library" for
consistency</li>
</ol></li>
</ul>
<p>JP 2: Accepted, fixed by c6552f06.</p>
<p>JP 3: <strong>CWG to handle issue</strong></p>
<ul>
<li>CWG wishes to investigate alternative wording changes.</li>
</ul>
<p>JP 4: Accepted, fixed by 76308413.</p>
<p>JP 5: Accepted, fixed by 3e0038a3.</p>
<p>JP 6, JP 7, JP 14, JP 16, JP 17: No consensus for change.</p>
<ul>
<li><p>The proposed change is not correct. The double-quote notation is used for the
canonical type names defined by the algorithm in [dcl.meaning]. In this context,</p>
<blockquote>
<p>function type <code>T</code></p>
</blockquote>
<p>means <code>T</code>, where <code>T</code> is a function type. The suggested alternative of</p>
<blockquote>
<p>''function type <code>T</code>''</p>
</blockquote>
<p>would be meaningless. We could change the wording to</p>
<blockquote>
<p>''array of <code>T</code>'' or function type ''<code>T</code>''</p>
</blockquote>
<p>but the convention is to omit the ''...'' when surrounding a single type name.</p></li>
</ul>
<p>JP 8: No consensus for change.</p>
<ul>
<li>The comment is not correct. <code>declarator ;</code> is a valid function declaration when
the declarator declares a constructor, destructor, or conversion function. The
wording is therefore correct as written.</li>
<li>The proposed alternative wording would fail to capture the intent that the
declartor shall be well-formed as a declarator for a complete
function-declaration (not merely a valid function declarator).</li>
</ul>
<p>JP 9: Accepted, fixed by aa74ca01.</p>
<p>JP 10, JP 11: No consensus for change.</p>
<ul>
<li>The core language portion of the standard intentionally does not have a
consistent "house style" used in examples, in order to emphasize that the
language itself takes no position on questions of style.</li>
</ul>
<p>JP 12: Accepted with modifications, fixed in b598c94e.</p>
<ul>
<li>Figure is referenced by number instead of as "below".</li>
</ul>
<p>JP 13: Accepted, fixed in ee809590.</p>
<p>JP 15: No consensus for change.</p>
<ul>
<li>12.5 does not appear to be relevant here. The cross-reference to 5.3.4 fully
describes how the matching deallocation function is determined. The
cross-reference to 3.7.4.2 is just for the term "deallocation function", and
covers both the class-specific and global cases.</li>
</ul>
<p>JP 18: Accepted with modifications, fixed in a8654e86.</p>
<ul>
<li>Solved by promoting the footnote into a note and splitting the surrounding
paragraph into multiple paragraphs.</li>
</ul>
<p>JP 21: Accepted, fixed in cf099ae6.</p>
<p>JP 22: Accepted with modifications, fixed in 472a7176.</p>
<ul>
<li>The wording has been simplified in a different way from that proposed.</li>
</ul>
<p>JP 23: Accepted with modifications.</p>
<ul>
<li>Each algorithm <em>with</em> a parallel form is now explicitly called out.</li>
<li>Duplicate of US 91.</li>
</ul>
<p>JP 24: Accepted, fixed in 984ef4a1.</p>
<p>JP 25: <strong>LWG to handle issue</strong></p>
<ul>
<li>This comment is not editorial.</li>
</ul>
<p>JP 26: Accepted, fixed by e229a482.</p>
<ul>
<li>Duplicate of US 182. </li>
</ul>
<h3>CA Comments</h3>
<p>No editorial comments.</p>
<h3>FI Comments</h3>
<p>No editorial comments.</p>
<h3>CH Comments</h3>
<p>No editorial comments.</p>
<h3>Late Comments</h3>
<p>Late 15: Accepted, fixed in 066aba68.</p>
<p>Late 30: <strong>LWG to handle issue</strong></p>
<ul>
<li>The change appears correct but LWG feedback is requested to ensure that the
<code>s1 == s2</code> check wasn't trying to check something else beyond the fact that
the paths resolve to the same file system entity.</li>
</ul>
<p>Late 42: Accepted, fixed in 3b22c874.</p>
<ul>
<li>Of note: the Postcondition is impossible to guarantee, due to the possibility
of a file system race.</li>
</ul>
<h2>Notable editorial changes</h2>
<p>The incorrect application of two papers, moved by prior meetings, have been fixed:</p>
<ul>
<li>In the application of P0035R4, the <code>__STDCPP_DEFAULT_NEW_ALIGNMENT__</code> macro
was accidentally added to the wrong paragraph of [cpp.predefined], making it
optional instead of mandatory. It has been moved to the correct paragraph.</li>
<li>In the application of P0135R1, wording allowing an rvalue reference to a
function to bind to the result of converting a class object to a function
lvalue via a conversion function was accidentally removed, and has been
restored.</li>
</ul>
<p>C.5 [diff.library] has received an overhaul in this revision of the
working draft. Consistent with the intent of Annex C, it has been updated to
comprehensively list all the known differences between the C standard library
and the corresponding C++ <code><X.h></code> stanard library headers. Thanks to Thomas
Köppe for this!</p>
<p>The index of implementation-defined behavior and index of library names have