-
Notifications
You must be signed in to change notification settings - Fork 17
/
P1018r8.bs
1367 lines (1279 loc) · 92.2 KB
/
P1018r8.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
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
<pre class='metadata'>
Title: C++ Language Evolution status 🦠 pandemic edition 🦠 2020/11–2021/01
Shortname: P1018
Revision: 8
Audience: WG21, EWG
Status: P
Group: WG21
URL: http://wg21.link/P1018r8
!Source: <a href="https://github.com/jfbastien/papers/blob/master/source/P1018r8.bs">github.com/jfbastien/papers/blob/master/source/P1018r8.bs</a>
Editor: JF Bastien, Woven Planet, cxx@jfbastien.com
Date: 2021-01-27
Markup Shorthands: markdown yes
Toggle Diffs: no
No abstract: false
Abstract: This paper is a collection of items that the C++ Language Evolution group has worked on in the latest meeting, their status, and plans for the future.
</pre>
Executive summary {#summary}
=================
We have not met in-person since the February 2020 meeting in Prague because of the global pandemic. We're instead holding weekly teleconferences, as detailed in [[P2145R1]]. We focus on providing non-final guidance, and will use electronic straw polls as detailed in [[P2195R0]] to move papers and issues forward in a asynchronous manner.
Our main achievements have been:
* **Issue processing**: most of the 50 language evolution issues have proposed resolutions.
* **C++23**: we've started work on papers for C++23 and later.
* **Incubation**: we've acted as EWG-I and "incubated" some early papers by providing early feedback to authors.
This paper outlines the work achieved, other ongoing work, and lists the straw polls that will be submitted for the February 2021 polling period.
Paper of note {#note}
=============
* [[P1000R4]] C++ IS schedule
* [[P0592R4]] To boldly suggest an overall plan for C++23
* [[P1999R0]] Process: double-check evolutionary material via a Tentatively Ready status
* [[P2195R0]] Electronic Straw Polls
* [[P2145R1]] Evolving C++ Remotely
Tentatively ready papers {#tentative}
========================
Following our process in [[P1999R0]], we usually mark papers as tentatively ready for CWG. We would usually take a brief look at the next meeting, and if nothing particular concerns anyone, send them to CWG. However, given the pandemic, we've decided to provide guidance only in virtual teleconferences, and have an asynchronous polling mechanism to officially send papers to CWG or other groups as detailed in [[P2195R0]]. We will be polling to advance all of these papers in the February 2021 polling period, and therefore avoid listing them twice in this paper.
You can follow the lists of papers on GitHub:
* <a href="https://github.com/cplusplus/papers/labels/TentativelyReady">tentatively ready papers</a>,
* <a href="https://github.com/cplusplus/papers/labels/EWG-vote-on-me">EWG vote on me papers</a>.
Issue Processing {#issue-pro}
================
We've reviewed 50 Language Evolution issues at the Core groups' request, and have tentative resolutions for most. We don't want to poll all of these at the same time, and will therefore only poll a subset in the February 2021 polling period, reserving other issues for later polling periods. We will therefore only poll the "tentatively ready" issues (since they're tied to papers, and polled with said papers, as outlined below), as well as the "resolved" issues since telecon attendees believe that prior work has already addressed the issues.
[[#issues]] contains a list of issues which aren't being voted on in this polling period.
Polls {#polls}
=====
The current list of polls which EWG will take in the February 2021 polling period are:
P2223R1 Trimming whitespaces before line splicing {#P2223R1}
-----------------------------------------------------
* [[P2223R1]]
* <a href="https://github.com/cplusplus/papers/issues/925">GitHub issue</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG14-Oct-2020">Notes 2020-10-14</a>
* Not yet seen by WG14, nor the SG22 C / C++ liaison group.
* <strong>Highlight:</strong> make trailing whitespaces after <code>\</code> non-significant.
* 🗳 <strong>Poll:</strong> Forward P2223R1 "Trimming whitespaces before line splicing" to Core, thereby also fixing [[CWG1698]].
P2201R0 Mixed string literal concatenation {#P2201R0}
-----------------------------------------------------
* [[P2201R0]]
* <a href="https://github.com/cplusplus/papers/issues/905">GitHub issue</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2013R2FreestandingLanguage:Optional::operatorNewP2201R0MixedStringLiteralConcatenation-19-Aug-2020">Notes 2020-08-19</a>
* Seen by WG14 as [[N2594]], straw Poll: Does the committee wish to adopt N2594 into C23 as is? 18-0-2 passes.
* <strong>Highlight:</strong> string concatenation involving string-literals with <em>encoding-prefixes</em> mixing `L""`, `u8""`, `u""`, and `U""` is currently conditionally-supported with implementation-defined behavior, this paper makes it ill-formed.
* 🗳 <strong>Poll:</strong> Forward P2201R0 "Mixed string literal concatenation" to Core, after adding an Annex C entry.
P2186R1 Removing Garbage Collection Support {#P2186R1}
-----------------------------------------------------
* [[P2186R1]]
* <a href="https://github.com/cplusplus/papers/issues/898">GitHub issue</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2139R2ReviewingDeprecatedFacilitiesOfC20ForC23P2186R0RemovingGarbageCollectionSupport-30-July-2020">Notes 2020-07-03</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/P2186">Notes 2020-12-14</a>
* <strong>Highlight:</strong> remove (not deprecate) garbage collection support in C++23.
* 🗳 <strong>Poll:</strong> Forward P2186R1 "Removing Garbage Collection Support" to Core.
P2173R0 Attributes on Lambda-Expressions {#P2173R0}
-----------------------------------------------------
* [[P2173R0]]
* <a href="https://github.com/cplusplus/papers/issues/882">GitHub issue</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020">Notes 2020-04-23</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2156-P2173-2-July-2020">Notes 2020-07-02</a>
* <strong>Highlight:</strong> allow attributes for lambdas, those attributes appertaining to the function call operator of the lambda.
* 🗳 <strong>Poll:</strong> Forward P2173R0 "Attributes on Lambda-Expressions" to Core, thereby also fixing [[CWG2097]].
P2156R1 Allow Duplicate Attributes {#P2156R1}
-----------------------------------------------------
* [[P2156R1]]
* <a href="https://github.com/cplusplus/papers/issues/864">GitHub issue</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020">Notes 2020-04-15</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020">Notes 2020-04-23</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2156-P2173-2-July-2020">Notes 2020-07-02</a>
* Seen by WG14 as [[N2557]], straw Poll: Is the committee in favor of adopting N2557 into C23? 19-0-0 passes.
* <strong>Highlight:</strong> current limitations on duplicate attributes are inconsistent, this change removes all limitations on duplicate attributes in an attribute-list for all attributes that specify a limitation. This affects `carries_dependency`, `deprecated`, `fallthrough`, `likely`, `unlikely`, `unused`, `noreturn`, and `no_unique_address`.
* 🗳 <strong>Poll:</strong> Forward P2156R1 "Allow Duplicate Attributes" to Core, thereby also fixing [[CWG1914]].
P2013R3 Freestanding Language: Optional `::operator new` {#P2013R3}
-----------------------------------------------------
* [[P2013R3]]
* <a href="https://github.com/cplusplus/papers/issues/749">GitHub issue</a>
* <a href="https://wiki.edg.com/bin/view/Wg21prague/P2013R0-EWG">Notes 2020-02-14</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2013R2FreestandingLanguage:Optional::operatorNewP2201R0MixedStringLiteralConcatenation-19-Aug-2020">Notes 2020-08-19</a>
* Not yet seen by WG14, nor the SG22 C / C++ liaison group.
* <strong>Highlight:</strong> on freestanding C++ implementations, make the various default allocating `::operator new` optional. Placement `new` is still required. All `::operator delete` are still required. Hosted implementations are unchanged.
* 🗳 <strong>Poll:</strong> Forward P2013R3 "Freestanding Language: Optional `::operator new`" to Core.
P1949R6 C++ Identifier Syntax using Unicode Standard Annex 31 {#P1949R6}
-----------------------------------------------------
* [[P1949R6]]
* <a href="https://github.com/cplusplus/papers/issues/688">GitHub issue</a>
* <a href="https://github.com/sg16-unicode/sg16/issues/48">SG16 Unicode group tracking GitHub issue</a>
* C++20 NB comment <a href="https://github.com/cplusplus/nbballot/issues/28">NL029 05.10</a>
* <a href="http://wiki.edg.com/bin/view/Wg21belfast/SG16NBNL029">Notes 2019-12-19</a>
* <a href="http://wiki.edg.com/bin/view/Wg21prague/SG16P1949R1">Notes 2020-02-12</a>
* <a href="http://wiki.edg.com/bin/view/Wg21prague/SG17P1949R1">Notes 2020-02-13</a>
* <a href="https://wiki.edg.com/bin/view/Wg21prague/D1949R2-EWG">Notes 2020-02-14</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1949-18-June-2020">Notes 2020-06-18</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1949-24-Sep-2020">Notes 2020-09-24</a>
* Not yet seen by WG14, nor the SG22 C / C++ liaison group.
* <strong>Highlight:</strong> C++11 uses a hand-curated list of Unicode codepoints to determine which characters are allowed in identifiers. This is flawed in many ways outlined in the paper. Replace this hand-curated list with the Unicode consortium's recommendations for identifiers [[UAX31]].
* 🗳 <strong>Poll:</strong> Forward P1949R6 "C++ Identifier Syntax using Unicode Standard Annex 31" to Core.
P1938R2 `if consteval` {#P1938R2}
-----------------------------------------------------
* [[P1938R2]]
* <a href="https://github.com/cplusplus/papers/issues/677">GitHub issue</a>
* C++20 NB comment <a href="https://github.com/cplusplus/nbballot/issues/219">FR22 20.15.10</a>, discussed in <a href="http://wiki.edg.com/bin/view/Wg21belfast/FR222">Belfast</a>
* <a href="https://wiki.edg.com/bin/view/Wg21prague/P1938R0-EWG">Notes 2020-02-14</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-8-Oct-2020">Notes 2020-10-08</a>
* <strong>Highlight:</strong> C++20 added `std::is_constant_evaluated()` and `consteval`, which interact poorly with each other. This paper adds a new form of `if` statement to address the poor interaction.
* 🗳 <strong>Poll:</strong> Forward P1938R2 "`if consteval`" to Core.
P1847R3 Make declaration order layout mandated {#P1847R3}
-----------------------------------------------------
* [[P1847R3]]
* <a href="https://github.com/cplusplus/papers/issues/600">GitHub issue</a>
* <a href="https://wiki.edg.com/bin/view/Wg21belfast/P1847">Notes 2019-11-05</a>
* <a href="https://wiki.edg.com/bin/view/Wg21prague/P1847R2-EWG">Notes 2020-02-13</a>
* <strong>Highlight:</strong> C++ currently lets compilers reorder data member layout if they have different access controls. Compilers don't take advantage of this permission. This paper removes the unused flexibility.
* 🗳 <strong>Poll:</strong> Forward P1847R3 "Make declaration order layout mandated" to Core.
P1401R4 Narrowing contextual conversions to `bool` {#P1401R4}
-----------------------------------------------------
* [[P1401R4]]
* <a href="https://github.com/cplusplus/papers/issues/188">GitHub issue</a>
* Addresses [[CWG2320]], which was caused by resolving [[CWG2039]], see <a href="https://lists.isocpp.org/core/2016/09/0899.php">Richard Smith's email regarding this approach</a>.
* <a href="https://wiki.edg.com/bin/view/Wg21prague/P1401R2-EWG">Notes 2020-02-12</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-30-Sep-2020">Notes 2020-09-30</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG28-Oct-2020">Notes 2020-10-28</a>
* <strong>Highlight:</strong> allow conversions from integral types to type `bool` in `static_assert` and `if constexpr`-statements.
* 🗳 <strong>Poll:</strong> Forward P1401R4 "Narrowing contextual conversions to `bool`" to Core.
P1393R0 A General Property Customization Mechanism {#P1393R0}
-----------------------------------------------------
* [[P1393R0]]
* <a href="https://github.com/cplusplus/papers/issues/185">GitHub issue</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1393-21-May-2020">Notes 2020-05-21</a>
* <strong>Highlight:</strong> "properties" are a customization mechanism at the center of [[P0443R14]] executors. The proposed approach is library-only, but it could be possible to develop a language-based approach instead. The discussion and poll's goal are to avoid a late-changing redesign of executors based on wanting a language-based approach for customization.
* 🗳 <strong>Poll:</strong> We understand properties and think that specifying them purely in library is the right approach.
CWG2169 Narrowing conversions and overload resolution {#CWG2169}
-----------------------------------------------------
<ul>
<li>[[CWG2169]]
<li><blockquote>
<p>Current implementations ignore narrowing conversions during overload resolution, emitting a diagnostic if calling the selected function would involve narrowing. For example:
<pre>
struct s { long m };
struct ss { short m; };
void f( ss );
void f( s );
void g() {
f({ 1000000 }); // Ambiguous in spite of narrowing for f(ss)
}
</pre>
<p>However, the current wording of 12.4.3.1.5 [over.ics.list] paragraph 7 says,
<blockquote>Otherwise, if the parameter has an aggregate type which can be initialized from the initializer list according to the rules for aggregate initialization (9.4.1 [dcl.init.aggr]), the implicit conversion sequence is a user-defined conversion sequence with the second standard conversion sequence an identity conversion.</blockquote>
<p>In the example above, `ss` cannot be initialized from `{ 1000000 }` because of the narrowing conversion, so presumably `f(ss)` should not be considered. If this is not the intended outcome, paragraph 7 should be restated in terms of having an implicit conversion sequence, as in, e.g., bullet 9.1, instead of a valid initialization.
</blockquote></li>
<li><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-29-Apr-2020">Notes 2020-04-29</a>
<li><a href="https://lists.isocpp.org/ext/2020/10/15157.php">JF's email to EWG 2020-10-19</a>, with the follow-up suggestion that no paper was needed and CWG could resolve the issue if given guidance from EWG.
<li>🗳 <strong>Poll:</strong> Guidance to Core: implementations are right, the Standard needs to be fixed to address this issue by following existing implementations.
</ul>
CWG2355 Deducing <i>noexcept-specifiers</i> {#CWG2355}
-----------------------------------------------------
* [[CWG2355]]
* The list of deducible forms in 13.10.2.5 [temp.deduct.type] paragraph 8 does not include the ability to deduce the value of the constant in a noexcept-specifier, although implementations appear to allow it. Note: multiple standard library implementations rely on it.
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020">Notes 2020-05-07</a>
* 🗳 <strong>Poll:</strong> Guidance to Core: modify the Standard such that the value of a constant in a <i>noexcept-specifier</i> can be deduced.
CWG476 Determining the buffer size for placement `new` {#CWG476}
-----------------------------------------------------
* [[CWG476]]
* Resolved by [[CWG2382]] (no overhead for placement `new` for arrays). CWG2382 was moved in Belfast as part of [[P1969r0]].
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Notes 2020-04-09</a>
* 🗳 <strong>Poll:</strong> Mark CWG476 "Determining the buffer size for placement `new`" as resolved by P1969r0, and a duplicate of CWG2382.
CWG687 `template` keyword with <i>unqualified-id</i>s {#CWG687}
-----------------------------------------------------
* [[CWG687]]
* Resolved by [[P0846r0]]
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Notes 2020-04-09</a>
* 🗳 <strong>Poll:</strong> Mark CWG687 "`template` keyword with <i>unqualified-id</i>s" as resolved by P0846r0.
CWG1326 Deducing an array bound from an <i>initializer-list</i> {#CWG1326}
-----------------------------------------------------
* [[CWG1326]]
* Resolved by [[P0127R2]] Declaring non-type `template` parameters with `auto`, and [[CWG1591]].
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Notes 2020-04-09</a>
* 🗳 <strong>Poll:</strong> Mark CWG1326 "Deducing an array bound from an <i>initializer-list</i>" as resolved by P0127R2, and a duplicate of CWG1591.
CWG1331 `const` mismatch with defaulted copy constructor {#CWG1331}
-----------------------------------------------------
* [[CWG1331]]
* Resolved by [[P0641r2]] (whose title is Resolving Core Issue #1331, also resolves [[CWG1426]]).
* <a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup">Notes 2014-06-21</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Notes 2020-04-09</a>
* 🗳 <strong>Poll:</strong> Mark CWG1331 "`const` mismatch with defaulted copy constructor" as resolved by P0641r2.
CWG1393 Pack expansions in <i>using-declaration</i>s {#CWG1393}
-----------------------------------------------------
* [[CWG1393]]
* Resolved by [[P0195r2]] (same title as issue)
* <a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup">Notes 2014-06-21</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Notes 2020-04-09</a>
* 🗳 <strong>Poll:</strong> Mark CWG1393 "Pack expansions in <i>using-declaration</i>s" as resolved by P0195r2.
CWG1426 Allowing additional parameter types in defaulted functions {#CWG1426}
-----------------------------------------------------
* [[CWG1426]]
* Resolved by [[P0641r2]] (also resolves [[CWG1331]])
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Notes 2020-04-09</a>
* 🗳 <strong>Poll:</strong> Mark CWG1426 "Allowing additional parameter types in defaulted functions" as resolved by P0641r2.
CWG1561 Aggregates with empty base classes {#CWG1561}
-----------------------------------------------------
* [[CWG1561]]
* Resolved by [[P0017r1]] (which allowed aggregates to have base classes)
* <a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup">Notes 2014-06-21</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020">Notes 2020-04-15</a>
* 🗳 <strong>Poll:</strong> Mark CWG1561 "Aggregates with empty base classes" as resolved by P0017r1.
CWG1912 <i>exception-specification</i> of defaulted function {#CWG1912}
-----------------------------------------------------
* [[CWG1912]]
* The current rules requiring a defaulted member function to have an exception-specification compatible with that of the implicitly-declared function are overly constraining. It should be possible, for example, to specify that a defaulted move constructor will be non-throwing, based on knowledge available to the programmer, even if the implicitly-declared constructor would be throwing.
* Resolved by [[p1286r2]]
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020">Notes 2020-04-23</a>
* 🗳 <strong>Poll:</strong> Mark CWG1912 "<i>exception-specification</i> of defaulted function" as resolved by p1286r2.
CWG1931 Default-constructible and copy-assignable closure types {#CWG1931}
-----------------------------------------------------
* [[CWG1931]]
* Resolved by [[P0624r2]] Default constructible and assignable stateless lambdas
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020">Notes 2020-04-23</a>
* 🗳 <strong>Poll:</strong> Mark CWG1931 "Default-constructible and copy-assignable closure types" as resolved by P0624r2.
CWG2295 Aggregates with deleted defaulted constructors {#CWG2295}
-----------------------------------------------------
* [[CWG2295]]
* Should a class with a deleted non-user-provided default constructor be considered an aggregate?
* Resolved by [[P1008r1]] Prohibit aggregates with user-declared constructors
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020">Notes 2020-05-07</a>
* 🗳 <strong>Poll:</strong> Mark CWG2295 "Aggregates with deleted defaulted constructors" as resolved by P1008r1.
CWG2341 Structured bindings with `static` storage duration {#CWG2341}
-----------------------------------------------------
* [[CWG2341]]
* Resolved by [[P1091r3]] Extending structured bindings to be more like variable declarations
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020">Notes 2020-05-07</a>
* 🗳 <strong>Poll:</strong> Mark CWG2341 "Structured bindings with `static` storage duration" as resolved by P1091r3.
CWG2343 `void*` non-type template parameters {#CWG2343}
-----------------------------------------------------
* [[CWG2343]]
* According to 13.2 [temp.param] bullet 4.2, non-type template parameters of pointer type must be either pointer to object or pointer to function. This excludes `void*`, which is an object pointer but not a pointer to object. However, most or all current implementations accept `void*` as a non-type template parameter. Notes from the April, 2018 Core teleconference: Not all implementations accept a `void*` template parameter, so this should not be a DR if it is eventually adopted. Furthermore, there is some implementation divergence over the kinds of template arguments that can be passed to a `void*` template parameter.
* Resolved by [[P0732R2]] (which used `std::strong_ordering` in defining strong structural equality and used that for NTTPs) because [[P0515R3]] had given `<=>` the type `std::strong_ordering` for "object pointers" (which includes `void*`, even though void is not an object type). Later [[P1907R1]] replaced all that, saying simply that structural types (which include all scalar types) were acceptable, but that didn't change `void*`'s status. Davis <a href="http://lists.isocpp.org/ext/2020/05/13730.php">emailed EWG the above text</a>.
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020">Notes 2020-05-07</a>
* <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG28-Oct-2020">Notes 2020-10-28</a>
* 🗳 <strong>Poll:</strong> Mark CWG2343 "`void*` non-type template parameters" as resolved by P0732R2.
CWG??? unqualified lookup in <i>conversion-type-id</i>s (<a href="https://lists.isocpp.org/ext/2020/06/14037.php">Sent by Richard Smith to EWG, from CWG</a>) {#CWGZygoloid}
-----------------------------------------------------
<ul>
<li><blockquote>The basic situation looks like this:
<pre>
struct A {
struct B {};
operator B();
};
void f(A a) { a.operator B(); }
</pre>
There is a special-case lookup rule that allows this code to work: when looking up the `B` in `a.operator B()`, we look inside `a`. Presumably the intent is to allow `operator B` to be named in the same way when it’s referenced as it was named when it was declared. This is a fairly general rule: in `<some context>operator B`, we look up the `B` in the same place in which we later look up the name `operator B`.
<p><em>Question</em> The issue we are facing is: exactly what lookups does the special-case rule apply to? Consider a few examples:
<pre>
a.operator B<C>();
a.operator B D::*();
a.operator decltype(E)();
</pre>
Which of `B`, `C`, `D`, and `E` get the special "look this name up in `a`" rule?
<p>There is implementation divergence:
<ul>
<li>Clang says none.
<li>EDG and MSVC say `B` only.
<li>GCC says `B` and `D`.
<li>And the consistent rules we're looking at now would say all of `B`, `C`, `D`, and `E` are looked up in `A`.
</ul>
</blockquote>
</li>
<li>Resolved by [[P1787R6]].
<li><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG28-Oct-2020">Notes 2020-10-28</a>
<li>🗳 <strong>Poll:</strong> Mark the CWG issue sent by Richard Smith to EWG on 2020-06 "unqualified lookup in <i>conversion-type-id</i>s" as resolved by P1787R6.
</ul>
For each poll, you will be asked to vote one of:
* Strongly in favor
* In favor
* Neutral
* Against
* Strongly against
You will also have the option to abstain from voting on a particular poll. You will be asked to comment on each poll. This comment is mandatory, as it helps the chair determine consensus.
Teleconferences {#telecons}
===============
Here are the minutes for the virtual discussions that were held since the Prague meeting in February 2020:
<ol>
<li>2020-04-09 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020">Issue Processing</a>
<li>2020-04-15 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020">Issue Processing</a>
<li>2020-04-23 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020">Issue Processing</a>
<li>2020-04-29 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-29-Apr-2020">Issue Processing</a>
<li>2020-05-07 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020">Issue Processing</a>
<li>2020-05-13 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-13-May-2020">Issue Processing</a>
<li>2020-05-21 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1393-21-May-2020">A General Property Customization Mechanism</a>—[[P1393R0]] (<a href="https://wg21.link/P1393/github">P1393 tracking issue</a>)
<li>2020-06-10 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-D2139R1-10-June-2020">Reviewing Deprecated Facilities of C++20 for C++23</a>—[[P2139R1]] (<a href="https://wg21.link/P2139/github">P2139 tracking issue</a>)
<li>2020-06-18 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1949-18-June-2020">C++ Identifier Syntax using Unicode Standard Annex 31</a>—[[P1949R4]] (<a href="https://wg21.link/P1949/github">P1949 tracking issue</a>)
<li>2020-06-24 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1467-24-June-2020">Extended floating-point types and standard names</a>—[[P1467R4]] (<a href="https://wg21.link/P1467/github">P1467 tracking issue</a>)
<li>2020-07-02 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2156-P2173-2-July-2020">Allow Duplicate Attributes, Attributes on Lambda-Expressions</a>—[[P2156R0]] (<a href="https://wg21.link/P2156/github">P2156 tracking issue</a>) and [[P2173R0]] (<a href="https://wg21.link/P2173/github">P2173 tracking issue</a>)
<li>2020-07-08 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1726R3-8-July-2020">Pointer lifetime-end zap and provenance, too</a>—[[P1726R3]] (<a href="https://wg21.link/P1726/github">P1726 tracking issue</a>)
<li>2020-07-16 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1726R3-16-July-2020">Guaranteed copy elision for return variables</a>—[[P2025R1]] (<a href="https://wg21.link/P2025/github">P2025 tracking issue</a>)
<li>2020-07-30 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2139R2ReviewingDeprecatedFacilitiesOfC20ForC23P2186R0RemovingGarbageCollectionSupport-30-July-2020">Reviewing Deprecated Facilities of C++20 for C++23, Removing Garbage Collection Support</a>—[[P2139R2]] (<a href="https://wg21.link/P2139/github">P2139 tracking issue</a>) and [[P2186R0]] (<a href="https://wg21.link/P2186/github">P2186 tracking issue</a>)
<li>2020-08-05 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1875R0-5-Aug-2020">Transactional Memory Lite Support in C++</a>—[[P1875R0]] (<a href="https://wg21.link/P1875/github">P1875 tracking issue</a>)
<li>2020-08-19 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2013R2FreestandingLanguage:Optional::operatorNewP2201R0MixedStringLiteralConcatenation-19-Aug-2020">Freestanding Language: Optional `::operator new`, Mixed string literal concatenation</a>—[[P2013R2]] (<a href="https://wg21.link/P2013/github">P2013 tracking issue</a>) and [[P2201R0]] (<a href="https://wg21.link/P2201/github">P2201 tracking issue</a>)
<li>2020-08-27 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-D2211R0-27-Aug-2020">Exhaustiveness Checking for Pattern Matching</a>—[[P1371R3]] (<a href="https://wg21.link/P1371/github">P1371 tracking issue</a>)
<li>2020-09-02 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1967-02-Sep-2020">`#embed` - a simple, scannable preprocessor-based resource acquisition method</a>—[[P1967R2]] (<a href="https://wg21.link/P1967/github">P1967 tracking issue</a>)
<li>2020-09-10 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P2011R1-10-Sep-2020">A pipeline-rewrite operator</a>—[[P2011R1]] (<a href="https://wg21.link/P2011/github">P2011 tracking issue</a>)
<li>2020-09-16 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1371-16-Sep-2020">Pattern matching: inspect is always an expression</a>—[[P1371R3]] (<a href="https://wg21.link/P1371/github">P1371 tracking issue</a>)
<li>2020-09-24 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-P1949-24-Sep-2020">C++ Identifier Syntax using Unicode Standard Annex 31, Member Templates for Local Classes</a>—[[P1949R6]] (<a href="https://wg21.link/P1949/github">P1949 tracking issue</a>) and [[P2044R0]] (<a href="https://wg21.link/P2044/github">P2044 tracking issue</a>)
<li>2020-09-30 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-30-Sep-2020">Narrowing contextual conversions to bool, Generalized pack declaration and usage</a>—[[P1401R3]] (<a href="https://wg21.link/P1401/github">P1401 tracking issue</a>) and [[P1858R2]] (<a href="https://wg21.link/P1858/github">P1858 tracking issue</a>)
<li>2020-10-08 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-8-Oct-2020">Compound Literals, `if consteval`</a>—[[P2174R0]] (<a href="https://wg21.link/P2174/github">P2174 tracking issue</a>) and [[P1938R1]] (<a href="https://wg21.link/P1938/github">P1938 tracking issue</a>)
<li>2020-10-14 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG14-Oct-2020">Inline Namespaces: Fragility Bites, Trimming whitespaces before line splicing</a>—[[P1701R1]] (<a href="https://wg21.link/P1701/github">P1701 tracking issue</a>) and [[P2223R0]] (<a href="https://wg21.link/P2223/github">P2223 tracking issue</a>)
<li>2020-10-22 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG22-Oct-2020">Issues Processing</a>
<li>2020-10-28 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG28-Oct-2020">Issues Processing</a>
<li>2020-11-05 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG05-Nov-2020">Deducing <code>this</code></a>—<a href="https://wg21.link/P0847r5">P0847R5</a> (<a href="https://wg21.link/P0847/github">P0847 tracking issue</a>)
<li>2020-11-19 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG19-Nov-2020"><code>goto</code> in pattern matching</a>
<li>2020-12-03 <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG03-Dec-2020"><code>auto(x)</code>: decay-copy in the language</a>—<a href="https://wg21.link/P0849r5">P0849R5</a> (<a href="https://wg21.link/P0849/github">P0849 tracking issue</a>)
<li>2021-01-14 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/Polls-2021-01-14">Polls</a>
</ol>
Remaining Open Issues {#issues}
=====================
The following table lists all remaining open issues referred to EWG by Core or Library. Some of them are ready to be polled but are held back from the February 2021 polling period to limit the number of polls in this round.
<table cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td valign="middle">
<p><b>From</b></p>
</td>
<td valign="top">
<p><b>#</b></p>
</td>
<td valign="top">
<p><b>Title</b></p>
</td>
<td valign="top">
<p><b>Notes</b></p>
</td>
<td valign="top">
<p><b>Resolution</b></p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG2261]]</p>
</td>
<td valign="top">
<p>Explicit instantiation of in-class `friend` definition</p>
</td>
<td valign="top">
<pre>
struct S {
template <class T> friend void f(T) { }
};
template void f(int); // Well-formed?
</pre>
<p>A `friend` is not found by ordinary name lookup until it is explicitly declared in the containing namespace, but declaration matching does not use ordinary name lookup. There is implementation divergence on the handling of this example.</p>
<p><br></p>
<p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-29-Apr-2020">Note 2020-04-29</a> Tentative agreement: This should be well-formed.</p>
<p>SF 1 F 10 N 2 A 1 SA 0 </p>
<p>JF <a href="https://lists.isocpp.org/ext/2020/05/13708.php"><span>emailed EWG / Core about this</span></a>.</p>
<p>Davis: the current name lookup approach which Core is taking in p1787 would disallow this. Supporting this is possible, it would be inconsistent, but would also be a feature.</p>
<p><a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG22-Oct-2020">Notes 2020-10-22</a>: wait until p1787 is voted into the working draft, because it’s making this behavior intentional. At that point, we can vote on marking the issue as Not a Defect. No objection to unanimous consent.</p>
</td>
<td valign="top">
<p>♻️</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG2270]]</p>
</td>
<td valign="top">
<p>Non-`inline` functions and explicit instantiation declarations</p>
</td>
<td valign="top">
<p>[Detailed description pending.]</p>
<p><b>Hubert:</b> question over the role of the `inline` keyword in relation to explicit instantiation declarations.</p>
<p>For `inline` functions, explicit instantiation declarations do not have the effect of suppressing implicit instantiation.</p>
<p>A user's desire for wanting to suppress implicit instantiation can arise for different reasons:</p>
<p>To reduce space in object files, executables, etc. and similarly to reduce the number of input symbols to the linker</p>
<p>To reduce compile time in performing semantic analysis for instantiations whose definitions are provided elsewhere</p>
<p>To control point-of-instantiation, avoiding contexts where the requisite declarations are not declared</p>
<p>The special rule around inline functions allows `inline`-ness to be used to indicate that the first reason is the intent and that instantiation-for-inlining is okay.</p>
<p>Consider the following as a translation unit:</p>
<pre>
template <typename T>
//inline
void f(T t) { g(t); }
enum E : int;
extern template void f(E);
void h(E e) { f(e); }
</pre>
<p>Marking the template definition `inline` would mean that the intended declaration for `g` would need to be provided as the best candidate at the points-of-instantiation for `f<E>`.</p>
<p>The issue initially points out that this use of the `inline` keyword does not match a view that `inline` is essentially an ODR tool to allow multiple definitions (as opposed to a way to indicate desire for inlining) and proposed that `extern template` merely has the effect of suppressing definitions in terms of linkage (regardless of the `inline` keyword). Such a change would affect the usability of the feature for user intent that falls within the latter two options above.</p>
<p>I am not sure if CWG is asking EWG a specific question other than the general "we do not believe this is a wording or obvious consistency issue; is this an issue in terms of design?"</p>
<p><b>Meeting:</b></p>
<p>Hubert <a href="https://lists.isocpp.org/ext/2020/05/13799.php"><span>forked the thread on the reflector</span></a>. Might want the education SG to take a look, or might want a paper.</p>
<p><b>Meeting 2020-10-28</b>: Inbal will try to put together the wording, to prove / disprove whether this is a defect.</p>
</td>
<td valign="top">
<p>♻️</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Lib</p>
</td>
<td valign="top">
<p>[[LWG2432]]</p>
</td>
<td valign="top">
<p>initializer_list assignability</p>
</td>
<td valign="top">
<p>std::initializer_list::operator= [support.initlist] is horribly broken and it needs deprecation:</p>
<p><br></p>
<p>std::initializer_list<foo> a = {{1}, {2}, {3}};</p>
<p>a = {{4}, {5}, {6}};</p>
<p>// New sequence is already destroyed.</p>
<p><br></p>
<p>Assignability of initializer_list isn't explicitly specified, but most implementations supply a default assignment operator. I'm not sure what [description] says, but it probably doesn't matter.</p>
<p><br></p>
<p><b>Proposed resolution:</b></p>
<p><br></p>
<p>Edit [support.initlist] p1, class template initializer_list synopsis, as indicated:</p>
<p><br></p>
<p>namespace std {</p>
<p> template<class E> class initializer_list {</p>
<p> public:</p>
<p> […]</p>
<p> constexpr initializer_list() noexcept;</p>
<p> </p>
<p> initializer_list(const initializer_list&) = default;</p>
<p> initializer_list(initializer_list&&) = default;</p>
<p> initializer_list& operator=(const initializer_list&) = delete;</p>
<p> initializer_list& operator=(initializer_list&&) = delete;</p>
<p> </p>
<p> constexpr size_t size() const noexcept;</p>
<p> […]</p>
<p> };</p>
<p> […]</p>
<p>}</p>
<p><br></p>
<p><span><a href="http://wiki.edg.com/bin/view/Wg21cologne/LWGTelecon-2014-12-18">LWG telecon</a></span> appears to want a language change to disallow assigning a braced-init-list to an std::initializer_list but still permit move assignment of std::initializer_list objects. That is,</p>
<p><br></p>
<p>auto il1 = {1,2,3};</p>
<p>auto il2 = {4,5,6};</p>
<p>il1 = {7,8,9}; // currently well-formed but dangles immediately; should be ill-formed</p>
<p>il1 = std::move(il2); // currently well-formed and should remain so</p>
<p><br></p>
<p><b>Meeting:</b> Proposed resolution:</p>
<pre>
initializer_list(const initializer_list&) = default;
initializer_list(initializer_list&&) = default;
[[deprecated]] initializer_list& operator=(const initializer_list&) = default;
[[deprecated]] initializer_list& operator=(initializer_list&&) = default;
</pre>
<p>SF F N A SA</p>
<p>0 3 12 0 0</p>
<p>JF <a href="https://lists.isocpp.org/lib-ext/2020/05/15334.php"><span>emailed LEWG</span></a>, to see if they have an opinion, no feedback. Asked LEWG chairs to schedule for a telecon.</p>
<p><span><a href="https://lists.isocpp.org/lib/2020/10/17760.php">LWG discussed</a></span> priority.</p>
</td>
<td valign="top">
<p>♻️</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Lib</p>
</td>
<td valign="top">
<p>[[LWG2813]]</p>
</td>
<td valign="top">
<p>std::function should not return dangling references</p>
</td>
<td valign="top">
<p>If a std::function has a reference as a return type, and that reference binds to a prvalue returned by the callable that it wraps, then the reference is always dangling. Because any use of such a reference results in undefined behaviour, the std::function should not be allowed to be initialized with such a callable. Instead, the program should be ill-formed.</p>
<p><br></p>
<p>A minimal example of well-formed code under the current standard that exhibits this issue:</p>
<p><br></p>
<p>int main() {</p>
<p> std::function<const int&()> F([]{ return 42; });</p>
<p> int x = F(); // oops!</p>
<p>}</p>
<p><br></p>
<p><b>Proposed resolution:</b></p>
<p><br></p>
<p>Add a second paragraph to the remarks section of 20.14.16.2.1 [func.wrap.func.con]:</p>
<p><br></p>
<p>template<class F> function(F f);</p>
<p>-7- Requires: F shall be CopyConstructible.</p>
<p>-8- Remarks: This constructor template shall not participate in overload resolution unless</p>
<ul>
<li><span></span>F is Lvalue-Callable (20.14.16.2 [func.wrap.func]) for argument types ArgTypes... and return type R, and<br>
</li>
<li><span></span>If R is type "reference to T" and INVOKE(ArgTypes...) has value category V and type U:<br>
</li>
<ul>
<li><span></span>V is a prvalue, U is a class type, and T is not reference-related (9.4.3 [dcl.init.ref]) to U, and<br>
</li>
<li><span></span>V is an lvalue or xvalue, and either U is a class type or T is reference-related to U.<br>
</li>
</ul>
</ul>
<p>[…]</p>
<p><br></p>
<p><b>Tim:</b> LWG in Batavia 2018 would like a way to detect when the initialization of a reference would bind it to a temporary. This requires compiler support, since there's no known way in the current language to do so reliably in the presence of user-defined conversions (see thread starting at <a href="https://lists.isocpp.org/lib/2017/07/3256.php"><span>https://lists.isocpp.org/lib/2017/07/3256.php</span></a>).</p>
<p><br></p>
<p><b>Meeting:</b> </p>
<p>Tim wrote <a href="https://wg21.link/p2255"><span>p2255</span></a> to address this.</p>
<p>Ville thinks there should be an analysis of alternative approaches.</p>
<p>Also see <a href="http://wg21.link/P0932"><span>P0932</span></a>.</p>
</td>
<td valign="top">
<p>♻️</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG728]]</p>
</td>
<td valign="top">
<p>Restrictions on local classes</p>
</td>
<td valign="top">
<p>Now that the restriction against local classes being used as template arguments has been lifted, they are more useful, yet they are still crippled. For some reason or oversight, the restriction against local classes being templates or having member templates was not lifted. Allowing local classes to have member templates facilitates generic programming (the reason for lifting the other restriction), especially when it comes to the visitor-pattern (see the boost::variant documentation and the following example) as implemented in boost and the boost::MPL library (since functors have to be template classes in mpl, and higher-order functors have to have member templates to be useful). A local class with a member template would allow this desirable solution:</p>
<p> #include <boost/variant.hpp></p>
<p> int main() {</p>
<p> struct times_two_generic: public boost::static_visitor<> {</p>
<p> template <typename T> void operator()(T& operand) const {</p>
<p> operand += operand;</p>
<p> }</p>
<p> };</p>
<p> std::vector<boost::variant<int, std::string>> vec;</p>
<p> vec.push_back(21);</p>
<p> vec.push_back("hello ");</p>
<p> times_two_generic visitor;</p>
<p> std::for_each(vec.begin(), vec.end(), boost::apply_visitor(visitor));</p>
<p> }</p>
<p>Is there any compelling reason not to allow this code? Is there any compelling reason not to allow local classes to be templates, have friends, or be able to define their static data members at function scope? Wouldn't this symmetry amongst local and non-local classes make the language more appealing and less embarrassing?</p>
<p>Also see <a href="http://wg21.link/p2044"><span>p2044</span></a>, seen by EWGI in Prague and requested to be merged with <a href="http://wg21.link/P1988"><span>P1988</span></a>, and implementors queried.</p>
<p><span><a href="https://isocpp.org/files/papers/D2044R2.pdf">The current paper draft</a></span> addresses all of this.</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>)</p>
<p>Some folks unsure that we should do anything here. Revisit the resolution with P2044.</p>
<p>Extension issues are a closed status on the issues list, like NAD Future was for LWG I find it helpful to have a status that says EWG may still be considering it.</p>
<p>Suggest closing as Not A Defect because we have significant implementation concerns, but we’ll explore the design space in P2044. All in favor.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG794]]</p>
</td>
<td valign="top">
<p>Base-derived conversion in member type of pointer-to-member conversion</p>
</td>
<td valign="top">
<p>Related to <a href="http://wg21.link/cwg170"><span>CWG 170</span></a>, drafting by Clark seems unlikely. This is section 2.1 of Jeff Snyder's <a href="http://wg21.link/P0149R0"><span>P0149R0</span></a>, which was approved by EWG, <a href="http://wiki.edg.com/bin/view/Wg21oulu/P0149R0"><span>4 years ago</span></a>, waiting for wording.</p>
<p>JF reached out to Jeff. Did wording with Jens, main blocker is lack of implementation.</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>) Suggest closing as Not A Defect because we have implementation uncertainties, but we’ll explore the design space in P0149. ABI group will discuss. All in favor.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG900]]</p>
</td>
<td valign="top">
<p>Lifetime of temporaries in range-based for</p>
</td>
<td valign="top">
<p>// some function</p>
<p> std::vector<int> foo();</p>
<p> // correct usage</p>
<p> auto v = foo();</p>
<p> for( auto i : reverse(v) ) { std::cout << i << std::endl; }</p>
<p> // problematic usage</p>
<p> for( auto i : reverse(foo()) ) { std::cout << i << std::endl; }</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>, also <a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup"><span>discussed in Rapperswil 2014</span></a>) Suggest closing as Not A Defect because it’s a change which might have effects on existing code (might cause bugs), and might need to change more than just range-based loops. See <a href="http://wg21.link/p0614"><span>p0614</span></a>, <a href="http://wg21.link/p0577"><span>p0577</span></a>, <a href="http://wg21.link/p0936"><span>p0936</span></a>, <a href="http://wg21.link/p1179"><span>p1179</span></a>. We’ll explore the design space in a separate paper, Herb circled back with Nico on this, might write a paper. All in favor.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG944]]</p>
</td>
<td valign="top">
<p>reinterpret_cast for all types with the same size and alignment</p>
</td>
<td valign="top">
<p>During the discussion of issue <a href="http://wg21.link/cwg799"><span>799</span></a>, which specified the result of using reinterpret_cast to convert an operand to its own type, it was observed that it is probably reasonable to allow reinterpret_cast between any two types that have the same size and alignment.</p>
<p>Additional note, April, 2015: It has been suggested that this question may more properly be the province of EWG, especially in light of discussions during the resolution of issue <a href="http://wg21.link/cwg330"><span>330</span></a>. The priority has been deleted to allow CWG to reconsider its status.</p>
<p>Rationale (May, 2015): CWG agreed that this question should be considered from a language design perspective and is thus being referred to EWG.</p>
<p>Suggest rejection: we chose to add std::bit_cast to provide exactly this functionality instead of extending reinterpret_cast.</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>) Suggest closing as Not A Defect. bit_cast addresses some of the usecases this issue might cover. We’d want separate papers to support other usescases, but have nothing outstanding at the moment. All in favor.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1008]]</p>
</td>
<td valign="top">
<p>Querying the alignment of an object</p>
</td>
<td valign="top">
<p><span><a href="https://godbolt.org/z/_SN8iF">https://godbolt.org/z/_SN8iF</a></span></p>
<ul>
<li><span></span>GCC already implements this extension without issuing a warning</li>
<li><span></span>Clang and EDG implement this extension for gcc compatibility, with a warning</li>
<li><span></span>MSVC does not yet implement this feature</li>
</ul>
<p>Quick example using ‘auto’ illustrates why we might want this capability for objects as well as types.</p>
<p>Principle of least astonishment suggests it is surprising for sizeof and alignof to behave differently in this regard.</p>
<p>Recommend shipping this straight to core as soon as we can find a wording champion.</p>
<p>We need to discuss with WG14.</p>
<p>Questions for EWG to answer before forwarding:</p>
<ul>
<li><span></span>Should this be a unary operator, like sizeof, so "alignof x" is valid? Or should it be like typeid, where parens are required?</li>
<li><span></span>What would this mean? Is it the alignment of the type of the object? Or the compiler's best guess of the alignment of the expression itself? Should it take into account any facts that are known about the expression other than its type? If so, which ones? (For example, if applied to an expression x or e.x and x is declared with an `alignas` attribute, is that value returned?)</li>
</ul>
<p>This needs a design paper rather than going straight to core.</p>
<p><span><a href="https://godbolt.org/z/TeVA9T">https://godbolt.org/z/TeVA9T</a></span> GCC seems to report the alignment of the object not just of decltype(object).</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>, also <a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup"><span>discussed in Rapperswil 2014</span></a>) Suggest closing as Not A Defect, the design is complex especially around alignment of object versus type. Invite a paper, Inbal will pitch in, Alidair can collaborate. All in favor.</p>
<p>Inbal’s paper: <a href="http://wg21.link/P2152R0"><span>P2152R0</span></a></p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1077]]</p>
</td>
<td valign="top">
<p>Explicit specializations in non-containing namespaces</p>
</td>
<td valign="top">
<p>The current wording of 9.8.1.2 [namespace.memdef] and 13.9.3 [temp.expl.spec] requires that an explicit specialization be declared either in the same namespace as the template or in an enclosing namespace. It would be convenient to relax that requirement and allow the specialization to be declared in a non-enclosing namespace to which one or more if the template arguments belongs.</p>
<p>Additional note, April, 2015: See EWG issue <a href="http://wg21.link/cwg48"><span>48</span></a>.</p>
<p>Might allow us to revert <a href="http://wg21.link/cwg2061"><span>DR2061</span></a> and all the horribleness that created and described in <a href="http://wg21.link/p1701"><span>p1701</span></a>. The problem 1077 addresses is the motivating factor in dr2061.</p>
<p>Also see <a href="http://wg21.link/cwg2370"><span>CWG 2370</span></a>.</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Thursday9th-April-2020"><span>notes</span></a>) Suggest closing as Not A Defect. See <a href="http://wg21.link/p0665"><span>p0665</span></a>, <a href="http://wiki.edg.com/bin/view/Wg21rapperswil2018/P0665R1-Rap18"><span>minutes</span></a>. Continue under p0665 or a forked version of it. All in favor.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1433]]</p>
</td>
<td valign="top">
<p><i>trailing-return-type</i> and point of declaration</p>
</td>
<td valign="top">
<p>template <class T> T list(T x);</p>
<p> template <class H, class ...T></p>
<p> auto list(H h, T ...args) -> decltype(list(args...)); // list isn’t in scope in its own <i>trailing-return-type</i></p>
<p> auto list3 = list(1, 2, 3);</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>, also <a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup"><span>discussed in Rapperswil 2014</span></a>) there might be compiler divergence according to Daveed. Suggest closing as Not A Defect, it would be tricky to change behavior without ambiguity. "Fixing" this would break existing code that relies on seeing only previous declarations. No objection to unanimous consent.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1451]]</p>
</td>
<td valign="top">
<p>Objects with no linkage in non-type template arguments</p>
</td>
<td valign="top">
<p>According to 13.4.2 [temp.arg.nontype] paragraph 1 bullet 3, only objects with linkage can be used to form non-type template arguments. Is this restriction still needed? It would be convenient to use block-scope objects as template arguments.</p>
<p>Resolved by <a href="http://wg21.link/N4268"><span>N4268</span></a>.</p>
<p>The following is valid:</p>
<p>template <int *> struct A;</p>
<p>auto f() {</p>
<p> static int x;</p>
<p> A<&x> *ap = nullptr;</p>
<p> return ap;</p>
<p>}</p>
<p>There is no longer any linkage restriction. There is a restriction on storage duration, which seems reasonable (you can use the address of a local static variable but not of a local automatic variable as a non-type template argument).</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>, also <a href="https://wiki.edg.com/bin/view/Wg21rapperswil2014/EvolutionWorkingGroup"><span>discussed in Rapperswil 2014</span></a>) Suggest closing as Not A Defect. Addressed by N4268. No objection to unanimous consent.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1469]]</p>
</td>
<td valign="top">
<p>Omitted bound in array <i>new-expression</i></p>
</td>
<td valign="top">
<p>The syntax for noptr-new-declarator in 7.6.2.7 [expr.new] paragraph 1 requires an expression, even though the bound could be inferred from a braced-init-list initializer. It is not clear whether 9.4.1 [dcl.init.aggr] paragraph 4, An array of unknown size initialized with a brace-enclosed initializer-list containing n initializer-clauses, where n shall be greater than zero, is defined as having n elements (9.3.3.4 [dcl.array]).</p>
<p>should be considered to apply to the new-type-id variant, e.g.,</p>
<p> new (int[]){1, 2, 3}</p>
<p>This was addressed by <a href="http://wg21.link/p1009"><span>p1009</span></a></p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>) Suggest closing as Not A Defect. Addressed by P1009. No objection to unanimous consent.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1555]]</p>
</td>
<td valign="top">
<p>Language linkage and function type compatibility</p>
</td>
<td valign="top">
<p>Currently function types with different language linkage are not compatible, and 7.6.1.2 [expr.call] paragraph 1 makes it undefined behavior to call a function via a type with a different language linkage. These features are generally not enforced by most current implementations (although some do) between functions with C and C++ language linkage. Should these restrictions be relaxed, perhaps as conditionally-supported behavior?</p>
<p>Somewhat related to CWG1463.</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>) no strong consensus at the moment, Erich Keane brought this up with SG12 Undefined Behavior. <a href="https://lists.isocpp.org/sg12/2020/05/0905.php"><span>Long discussion</span></a>, will need to revisit, need a paper.</p>
<p><b>Meeting Oct 22nd 2020:</b> will need a volunteer to write a paper, but the wording in the standard is unambiguous, and we have existence proof of platforms which use different calling conventions between C and C++. However many major compilers have chosen to ignore this. Not a defect, but we welcome a paper to change the status quo. No objection to unanimous consent.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1643]]</p>
</td>
<td valign="top">
<p>Default arguments for template parameter packs</p>
</td>
<td valign="top">
<p>Although 13.2 [temp.param] paragraph 9 forbids default arguments for template parameter packs, allowing them would make some program patterns easier to write. Should this restriction be removed?</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>) Suggest closing as Not A Defect. Interesting design space, but needs a paper, see N3416. No objection to unanimous consent.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1864]]</p>
</td>
<td valign="top">
<p>List-initialization of array objects</p>
</td>
<td valign="top">
<p>The resolution of issue <a href="http://wg21.link/cwg1467"><span>1467</span></a> now allows for initialization of aggregate classes from an object of the same type. Similar treatment should be afforded to array aggregates.</p>
<p>See recent discussion on allowing 'auto x[] = {1, 2, 3};' -- this topic came up there. The two questions can be answered independently, but some consider them to be related.</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes</span></a>) Suggest closing as Not A Defect. Fixing anything in this space would require a paper which considers the entire design space, Timur might be interested in this. No objection to unanimous consent.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1871]]</p>
</td>
<td valign="top">
<p>Non-identifier characters in <i>ud-suffix</i></p>
</td>
<td valign="top">
<p>JF forwarded to SG16 Unicode given their work on TR31. Tracked on <a href="https://github.com/sg16-unicode/sg16/issues/61"><span>GitHub</span></a>. SG16 reviewed D1949R3, still needs wording changes. Discussed at <a href="https://github.com/sg16-unicode/sg16-meetings#april-22nd-2020"><span>the April 22nd SG16 telecon</span></a>.</p>
<p><b>SG16 Poll:</b> Is there any objection to unanimous consent for recommending rejection of this proposal? No objection to unanimous consent.</p>
<p><b>EWG Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/IssueProcessing-Wednesday15th-April-2020"><span>notes 2020-04-15</span></a>, <a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-07-May-2020"><span>notes 2020-05-07</span></a>) Suggest closing as Not A Defect. No objection to unanimous consent.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1876]]</p>
</td>
<td valign="top">
<p>Preventing explicit specialization</p>
</td>
<td valign="top">
<p>A desire has been expressed for a mechanism to prevent explicitly specializing a given class template, in particular std::initializer_list and perhaps some others in the standard library. It is not clear whether simply adding a prohibition to the description of the templates in the library clauses would be sufficient or whether a core language mechanism is required.</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020"><span>notes</span></a>) Suggest closing as Not A Defect. No objection to unanimous consent. This could be a language feature, would need library usecase examples.</p>
<p><b>Poll:</b> we are interested in such a paper SF 2 F 13 N 6 A 1 SA 0</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1915]]</p>
</td>
<td valign="top">
<p>Potentially-invoked destructors in non-throwing constructors</p>
</td>
<td valign="top">
<p>Since the base class constructor is non-throwing, the deleted base class destructor need not be referenced.</p>
<p>There's a typo in the issues list here: it should say "Since the *derived* class constructor is non-throwing, the deleted base class destructor need not be referenced."</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020"><span>notes 2020-04-23</span></a>) the proposed wording changes the implementation leeway in two-phase unwinding, which breaks some existing ABIs. We would need a paper to explore this further. Suggest closing as Not A Defect. No objection to unanimous consent.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1923]]</p>
</td>
<td valign="top">
<p>Lvalues of type void</p>
</td>
<td valign="top">
<p>There does not seem to be any significant technical obstacle to allowing a void* pointer to be dereferenced, and that would avoid having to use weighty circumlocutions when casting to a reference to an object designated by such a pointer.</p>
<p>Might consider this a duplicate of the discussion on "regular void".</p>
<p>JF reached out to Matt. He has an implementation in clang. Needs to update the paper. Might need a volunteer to present. Daveed would be interested in presenting.</p>
<p><b>Meeting:</b> (<a href="https://wiki.edg.com/bin/view/Wg21summer2020/EWG-IssueProcessing-23-Apr-2020"><span>notes 2020-04-23</span></a>) Suggest closing as Not A Defect. Explore under the “regular void” umbrella. No objection to unanimous consent.</p>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<tr>
<td valign="top">
<p>Core</p>
</td>
<td valign="top">
<p>[[CWG1934]]</p>
</td>
<td valign="top">
<p>Relaxing <i>exception-specification</i> compatibility requirements</p>
</td>
<td valign="top">
<p>According to 14.5 [except.spec] paragraph 4,</p>
<p><br></p>
<p>If any declaration of a function has an exception-specification that is not a noexcept-specification allowing all exceptions, all declarations, including the definition and any explicit specialization, of that function shall have a compatible exception-specification.</p>
<p><br></p>
<p>This seems excessive for explicit specializations, considering that paragraph 6 applies a looser requirement for virtual functions:</p>
<p><br></p>
<p>If a virtual function has an exception-specification, all declarations, including the definition, of any function that overrides that virtual function in any derived class shall only allow exceptions that are allowed by the exception-specification of the base class virtual function.</p>
<p><br></p>
<p>The rule in paragraph 3 is also problematic in regard to explicit specializations of destructors and defaulted special member functions, as the implicit exception-specification of the template member function cannot be determined.</p>
<p><br></p>
<p>There is also a related problem with defaulted special member functions and exception-specifications. According to 9.5.2 [dcl.fct.def.default] paragraph 3,</p>
<p><br></p>
<p>If a function that is explicitly defaulted has an explicit exception-specification that is not compatible (14.5 [except.spec]) with the exception-specification on the implicit declaration, then</p>
<ul>
<li><span></span>if the function is explicitly defaulted on its first declaration, it is defined as deleted;</li>