-
Notifications
You must be signed in to change notification settings - Fork 17
/
P1018r15.bs
1469 lines (1356 loc) · 107 KB
/
P1018r15.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 🦠 2022/01–2022/02
Shortname: P1018
Revision: 15
Audience: WG21, EWG
Status: P
Group: WG21
URL: http://wg21.link/P1018r15
!Source: <a href="https://github.com/jfbastien/papers/blob/master/source/P1018r15.bs">github.com/jfbastien/papers/blob/master/source/P1018r15.bs</a>
Editor: JF Bastien, Woven Planet, cxx@jfbastien.com
Date: 2022-02-15
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>
<style>
table, th, td { border: 2px solid grey; }
</style>
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, and a large number of them have been voted on through electronic polling.
* **C++23**: we've worked on papers for C++23 and later. As of January 2022, EWG is not considering new papers for C++23.
* **Incubation**: we've acted as EWG-I and "incubated" some early papers by providing early feedback to authors.
This paper outlines:
* The work achieved in [[#telecons]];
* Lists the [[#polls]] results for the Early 2022 polling period and explain the [[#process]] (see [[P1018r9]] for the results of the February 2021 polling period, [[P1018r11]] for the results of the May 2021 polling period, and [[P1018r13]] for the results of the August polling period);
* Lists the remaining outstanding issues in [[#issues]], some are still open while others are waiting for polling;
* [[#future]].
Papers 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]].
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 therefore only poll a subset in each polling period, reserving other issues for later polling periods. We've therefore only polled 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 polls which EWG took in the January 2022 polling period, and the poll results, are:
P2280r3 Using unknown references in constant expressions {#P2280r3}
-------
* [[P2280r3]]
* <a href="https://github.com/cplusplus/papers/issues/973">GitHub issue</a>
* **Highlight:** `constexpr` usage of unknown references doesn't work, that's surprising, make it work as expected.
* **🗳 Poll:** Forward P2280r3 "Using unknown references in constant expressions" to Core for C++23. Treat it as a Defect Report.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>20</td><td>12</td><td>2</td><td>0</td><td>0</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 11</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Strong Favor:** While this paper de-fact introduce the special-case for the constexpr function, I think that it leads to more intuitive and teachable behaviour of constexpr functions.
<li>**Strong Favor:** This covers cases where the compiler knows what I am asking, but refuses to answer because it's not allowed to. This allows the compiler to tell me what it knows well.
<li>**Strong Favor:** It is pretty hard to explain to a non-language-lawyer why asking for the size of a by-reference `std::array` parameter is non-constant but doing so for a by-value `std::array` parameter is constant; and references `+` this seems like a good place to draw the line. Ship it.
<li>**Strong Favor:** I believe this is useful and relatively easily implementable.
<li>**Favor:** Constant evaluation is unequivocally weird: it can use non-static local variables initialized with constant expressions when no call to the function ever takes place, and it notionally occurs at runtime even though its failure can make the program ill-formed. This paper is in line with these properties, freely inventing objects with overlapping storage of types that can never be constructed and changing lvalues with known referents to refer to such phantoms instead. That said, the change somehow makes the language less surprising, as the frequency of confusion over the non-`static` `std::array::size` illustrates. As a matter of convenience, then, if not of coherence, it is an improvement.
</ul>
P2468r1 The Equality Operator You Are Looking For {#P2468r1}
-------
* [[P2468r1]]
* <a href="https://github.com/cplusplus/papers/issues/1127">GitHub issue</a>
* **Highlight:** Make rewriting equality in expressions less of a breaking change.
* **🗳 Poll:** Forward P2468r1 "The Equality Operator You Are Looking For" to Core for C++23. Treat it as a Defect Report against C++20.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>19</td><td>14</td><td>1</td><td>0</td><td>0</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 11</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Favor:** It is amazing that the new comparison rules continue to cause so much trouble after so much time. The examples given show that these revised rewrite rules are at the very least a significant improvement and should reduce the pain of updating existing code to newer language standards.
<li>**Favor:** This is a necessary update to C++20. Migration to C++20 did sometimes cost a lot of time due to the various issues mentioned in the paper.
<li>**Strong Favor:** Given that implementations are doing something along those lines to avoid breaking existing code already - ship it.
</ul>
P2327r1 De-deprecating `volatile` compound operations {#P2327r1}
-------
* [[P2327r1]]
* <a href="https://github.com/cplusplus/papers/issues/1023">GitHub issue</a>
* **Highlight:** C++20 deprecated many uses for `volatile`. This paper un-deprecates the bitwise compound operators (`|=`, `&=`,and `^=`) on `volatile` left operands.
* **🗳 Poll:** Forward P2327r1 "De-deprecating `volatile` compound operations" to Core for C++23. Treat it as a Defect Report against C++20.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>13</td><td>19</td><td>1</td><td>0</td><td>2</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 10</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Strong Favor:** The proposal retains compatibility with large swaths of often vendor-supplied hardware support libraries targeted at C. This makes C++ more viable in the embedded world. Programming patterns that embedded systems engineers are familiar with keep on working.
<li>**Strong Favor:** We want to increase the usage of C++ for embedded code; *not* doing this would alienate some users, and add more support for a "C++ is bad for embedded" position
<li>**Favor:** I can understand the problems caused by the C++20 change in that respect; the paper, however, does not fully address (it seems to me) the problems that led to the deprecation in the first place (the paper _does_ explain how these operations can be well used under specific circumstances and by specific parties, of course, but use of these operations is not limited to such parties and circumstances). I'm split, but will err on the side of trusting users...
<li>**Favor:** It is a misfeature of the language that volatility pertains equally to reads and writes despite the fact that memory-mapped devices are often simplex. It is the correct balance to allow programmers to idiomatically use objects associated with such devices even though, even on hardware that supports an appropriately atomic modification, the language does not provide a mechanism for the compound assignment operators to support full-duplex communication.
<li>**Strong Against:** To me, the semantic of the compound assignment is not well defined in the standard. It says: `E1 op= E2` is equivalent to `E1 = E1 op E2` except that `E1` is evaluated only once. This is not enough to define volatile semantics. We need to know how many read access and how many write access occur, in what order. The standard was unclear before, so be it. It was cleaned, that was good. Reintroducing inaccurately defined construct is not the right way to go. I would be in favor if the semantics were defined. The paper claims that deprecation(and eventually removal) will force developers to change the way they write embedded code. This is not true. Embedded compilers would probably support this construct as an extension, which is the right thing to do for something that has no clearly specified semantic (and I hope they will define the semantic they selected in their documentation).
<li>**Strong Against:** It is evident from discussion in and outside the committee that, while people are hurt by that depreciation, the semantics of compound assignments are too often assumed to be atomic or are otherwise unclear. The motivation for deprecating them hasn't disappear. It is important that the C committee and the industry follows suite with that - and it might take time. However, undeprecating them sends the wrong message, and still leaves users with the bugs the original paper was trying to correct.
</ul>
P2266r2 Simpler implicit move {#P2266r2}
-------
* [[P2266r2]]
* <a href="https://github.com/cplusplus/papers/issues/968">GitHub issue</a>
* **Highlight:** In C++20, `return` statements can *implicitly move* from local variables of *rvalue* reference type; but a defect in the wording means that *implicit move* fails to apply to functions that return references. C++20’s implicit move is specified via a complicated process involving two overload resolutions, which is hard to implement, causing implementation divergence. We fix the defect and simplify the spec by saying that a returned move-eligible *id-expression* is always an *xvalue*.
* **Note:** r1 of this paper went through electronic polling, received mixed feedback based on new information, see [[P1018r13]] for the poll comments. It was updated to r2, re-discussed in the <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-10-07">2021-10-07 teleconference</a> to address the new information, and is now being re-polled.
* **🗳 Poll:** Forward P2266r2 "Simpler implicit move" to Core for C++23.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>15</td><td>13</td><td>1</td><td>2</td><td>0</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 14</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Favor:** Reading through the rationale presented in the paper, I find that these rules are consistent with thinking of r-value references as "owning" in the sense that they represent a promise that modifications to the referenced object will not be observed except by components to which ownership is subsequently transferred. These rules changes preserve that intuitive property without requiring extra syntax.
<li>**Favor:** It's unfortunate to break any existing code doing something as simple as returning a local variable, but even within that set many cases are plainly bugs or were already broken by C++20. Given that the language has a means of identifying Xpiring values in the type system, it seems only appropriate to use it in such a particularly straightforward context.
<li>**Favor:** The current "implicit move" semantics for a return statement are unlike any other overload resolution mechanism in the language. So this seems like a good direction. I would have preferred also treating this as a defect report.
<li>**Favor:** "It is a simpler rule, but probably will have more downstream consequences than the ones presented here. It's hard to know what those are. I think we should really invest, as an organization, in the ability to test changes like this. If we had an implementation of `==`, and the ability to test this on many large code bases with test suites, we probably would've never had the problem that P2468 now has to solve. Here, we do have an implementation of this paper, and we have some feedback of its impact. But to what extent is this a thorough-enough testing? It'd be nice if we could actually provide a good answer to that question in a way that could give us the confidence to say "Yes, this breaks some code, in these situations, and that is okay." Today, the best I can do is vote FOR and hope that no further, larger issues will pop up."
<li>**Against:** Weakly against P2266 (vs strongly before). There hasn't been any glut of new errors, and the problems seem to have "settled" from the Clang implementation. That said, the throw-example still gives me heartburn, otherwise I have no implementation concerns.
<li>**Against:** This broke code in STL headers written by C++ experts; that gives me no confidence it won't also break user code in the wild, which may be written by less-expert folks. Thankfully, the breakages we saw at Intel finally stopped, which is why this is an Against instead of a Strongly Against (but I'm borderline strong on this).
</ul>
P1467r8 Extended floating-point types and standard names {#P1467r8}
-------
* [[P1467r8]]
* <a href="https://github.com/cplusplus/papers/issues/227">GitHub issue</a>
* **Highlight:** In addition to the three standard floating-point types, `float`, `double`, and `long double`, implementations may define any number of *extended floating-point types*, similar to how implementations may define extended integer types. An extended floating-point type may have the same representation and the same set of values as a standard floating-point type. But the extended floating-point type is still a separate type, and is not just an alias for the standard type. The proposal covers conversion rank, promotion, implicit conversion, usual arithmetic conversion, narrowing conversion, overload resolution, literal suffixes. It also contains library changes.
* **🗳 Poll:** Forward the language changes in P1467r8 "Extended floating-point types and standard names" to Core for C++23, assuming that Library Evolution will separately forward the library changes to Library for C++23.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>11</td><td>15</td><td>2</td><td>1</td><td>0</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 16</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Favor:** While the feature as proposed still has some rough edges (e.g., imperfect C compatibility and complicated overload resolution behavior), the numerous reviews have plainly identified the least problematic means of integrating several new fundamental types into the language. Those types are of increasing practical importance and have the hardware support appropriate for a language feature.
<li>**Favor:** This will allow C++ applications to take advantage of existing and yet-to-come floating-point hardware in a standard way.
<li>**Against:** The lack of implementation experience of the proposed overload resolution rules is concerning.
</ul>
P2350r2 `constexpr class` {#P2350r2}
-------
* [[P2350r2]]
* <a href="https://github.com/cplusplus/papers/issues/1028">GitHub issue</a>
* **Highlight:** Allow `constexpr` in the `class`-head, declaring that all member functions, including special member functions, in this `class` are implicitly `constexpr`.
* **🗳 Poll:** Forward P2350r2 "`constexpr class`" to Core for C++23.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>12</td><td>12</td><td>9</td><td>5</td><td>2</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 5</td></tr>
</table>
<br><strong>Poll outcome:</strong>❌ no consensus
<strong>Salient comments:</strong>
<ul>
<li>**Strong Favor:** The standard library is moving towards "constexpr all the things" as much as it makes sense. We're at the point where slapping a "constexpr" at every declaration in a class becomes a nuisance and mental burden. This should be avoided by moving the constexpr-ness of all direct class members up at the class level. Stuff that's not constexpr will then stand out as something to possibly reconsider in the design.
<li>**Strong Favor:** The code using this is way friendlier to read and maintain. The infrastructure was already introduced, so it is easy to teach and grok. If P2448 is accepted at the same time I see no downside.
<li>**Favor:** Useful to avoid a lot of boilerplate in modern code bases.
<li>**Against:** The value is IMO minimal, and I is going in the wrong direction of where constexpr is headed. Moving the annotation to the class makes the formerly "obvious" annotation less obvious.
<li>**Against:** Allowing `struct X constexpr ...` but not `struct X consteval ...` is suspect.
<li>**Against:** P2448 removes some of the important caveats to using this feature, but it remains a clever workaround for one of the defaults being wrong rather than a meaningful feature. The constexpr status of static data members seems orthogonal at best, such that this convenience encourages silly things like adding a base class to hold any non-constexpr ones.
<li>**Strong Against:** This goes into the wrong direction. Faced with the fantastic problem of everything being constexpr, WG21 should rather consider whether the keyword is useful at all. As pointed out by P2448, the constexpr keyword already offer no guarantee, and if it doesn't then maybe everything that can be called in a constant expression should be, and as such maybe an implenentation should always try to evaluate member function calls at constexpr. The feature proposed by P2350 is a short term solution that only works in very narrow cases, and adding a non constexpr function forces to modify the whole class.
<li>**Strong Against:** Applying constexpr on static member functions turns this feature into a different one. Now users will start open classes with all static member functions to write constexpr libraries because there is no other way in the language to mark a series of free functions with constexpr.
</ul>
P1169r3 `static operator()` {#P1169r3}
-------
* [[P1169r3]]
* <a href="https://github.com/cplusplus/papers/issues/1022">GitHub issue</a>
* **Highlight:** Allow declaring `operator()` as `static`, as well as making lambdas `static`.
* **🗳 Poll:** Forward P1169r3 "`static operator()`" to Core for C++23.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>16</td><td>16</td><td>3</td><td>1</td><td>1</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 8</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Strong Favor:** It is a little weird to exploit the ability to call static member functions via member-access syntax to allow a performance improvement, but the feature is valuable and the semantics are the only ones possible. Yet another default is now wrong (for captureless lambdas), although those are so often inlined that the practical impact may be small.
<li>**Strong Favor:** I have thought that this was possible many times only to find out (again) that it is not. Finally it will be.
<li>**Favor:** Sheds needless overhead.
<li>**Favor:** Seems generally useful. The restriction against static here seems arbitrary.
<li>**Against:** It's a patch
<li>**Strong Against:** This adds a lot of subtlety for very little gain in practice.
</ul>
P1774r5 Portable assumptions {#P1774r5}
-------
* [[P1774r5]]
* <a href="https://github.com/cplusplus/papers/issues/529">GitHub issue</a>
* **Highlight:** Add the <code>[[assume(<em>expression</em>)]]</code> attribute. The use of assumptions is intended to allow implementations to assume that a given expression is true, and to optimize the program based on that assumption.
* **🗳 Poll:** Forward P1774r5 "Portable assumptions" to Core for C++23.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>14</td><td>17</td><td>3</td><td>4</td><td>0</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 7</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Strong Favor:** There are use cases where assumptions can significantly improve performance and decrease code size, and they have been existing practice on all major compilers for many years, but in a non-standardised, non-unified, non-portable, not-very-well-defined way. This paper fixes it. I am strongly in favour of including this in C++23.
<li>**Strong Favor:** Useful tool for code optimization, impressive usage examples for the standard library
<li>**Against:** The specification of what this actually DOES is too handwavy for my comfort. I'm still not sure what the limitations being placed on the implementation are, and the paper's assumption (hah!) of how the current implementations of similar things seem to be misguided.
<li>**Against:** This tool is too sharp and too seductive. I expect it to introduce many new UB in user code, any many cases without measurable benefits.
<li>**Against:** high potential for overuse leading to serious errors
</ul>
P1494r2 Partial program correctness {#P1494r2}
-------
* [[P1494r2]]
* <a href="https://github.com/cplusplus/papers/issues/376">GitHub issue</a>
* **Highlight:** Adds `std::observable()` (<em>name pending LEWG review</em>) which establishes an observable checkpoint, inhibiting "time travel" of Undefined Behavior past the checkpoint.
* **🗳 Poll:** Forward P1494r2 "Partial program correctness" to Core for C++23, pending LEWG approval.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>10</td><td>7</td><td>3</td><td>4</td><td>1</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 20</td></tr>
</table>
<br><strong>Poll outcome:</strong>❌ no consensus
<strong>Salient comments:</strong>
<ul>
<li>**Strong Favor:** We need this to properly reason about asserts and contracts. Until we get full contracts this will help us to get the correct behaviour in user build solutions
<li>**Favor:** This is potentially useful, though I think its usefulness in practical terms is quite limited, as it's hard to imagine why I would reach for this unless I already thought I had UB that I needed to protect against -- in which case I would rather fix the UB. I could see myself using this feature while actively iterating on code, but I doubt I'd ever commit code with this in it.
<li>**Favor:** This proposal seems pretty wild, but I'm curious to see where it goes.
<li>**Favor:** This seems like a useful - if expert-only - feature.
<li>**Favor:** Useful, although I'm sure it will get misunderstood and misused.
<li>**Neutral:** In the war between programmer implicit assumptions, and what the compiler can observe, I am not confident this helps more than other rewrites that acknowledge UB that the compiler has noted.
<li>**Against:** I waffle back and forth between liking the idea and having no confidence we have any idea how well this will work in practice because there is zero implementation experience.
<li>**Against:** This seems to lack real implementation experience.
<li>**Strong Against:** This solves a problem.... that users don't know exist, in a way users won't know about. This is a very expert-friendly solution, for a very narrow set of experts. And unlike other esoteric language feature, this paper doesn't provide specific use cases where such an expert could significantly improve a program using this feature. Are we doing anything more than *technically* providing a solution? Where in my code, should i put that? I can only assume every other line of code i write triggers some UB, and so, should i add std::observable calls everywhere? The paper seems to be greatly concerned about I/O, was stating that returning from I/O functions constitute checkpoints considered?
</ul>
P2448r0 Relaxing some `constexpr` restrictions {#P2448r0}
-------
* [[P2448r0]]
* <a href="https://github.com/cplusplus/papers/issues/1119">GitHub issue</a>
* **Highlight:** Remove two rules about `constexpr` that make code ill-formed or ill-formed (no diagnostic required) when functions or function templates are marked `constexpr` that might never evaluate to a constant expression.
* **🗳 Poll:** Forward P2448r0 "Relaxing some `constexpr` restrictions" to Core for C++23. Treat it as a Defect Report.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>20</td><td>12</td><td>1</td><td>2</td><td>1</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 9</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Strong Favor:** Seems to go against the spirit of constexpr rules of just diagnosing things that aren't actually wrong, with the added harm that the rules aren't consistently enforced.
<li>**Favor:** This improves the usability of constexpr and the language as a whole. Implementation is trivial.
<li>**Favor:** This change is consistent with the general principle of diagnosing constexpr violations as they occur, rather than trying to predict whether or not a code path conforms to constexpr requirements. This is much more useful for programmers, particularly those who need to support multiple language dialects.
<li>**Neutral:** I cannot make my mind if helping experts that write code that works seamlessly with several versions of the standard is more or less important than helping beginners that may have just badly written a constexpr function... I would be in favor of beginners (and vote against this) if I trusted diagnostics to work well in many non-toy examples, but since I don't, I'll be neutral.
<li>**Against:** This paper removes any amount of value to the constexpr keyword; which is that the compiler will make SOME effort to validate its usability as constexpr. I don't like at all that this causes us to no longer catch some obvious mistakes in the user's code.
<li>**Strong Against:** Footgun. I do not agree with the logic that a function must be used to be checked for legality. Telling the user "this can NEVER be correct" is a powerful feature in the real world, where not every user tests every function immediately upon writing it. Why make them write the test when the compiler can tell them at compile time, which is the whole value-add for constexpr in the first place?
</ul>
P2437r0 Support for `#warning` {#P2437r0}
-------
* [[P2437r0]]
* <a href="https://github.com/cplusplus/papers/issues/1103">GitHub issue</a>
* **Highlight:** C23 is adding support for `#warning` as a complement to `#error`. Add it to C++23 as well.
* **🗳 Poll:** Forward P2437r0 "Support for `#warning`" to Core for C++23.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>26</td><td>11</td><td>2</td><td>0</td><td>0</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 6</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Favor:** Simple, straight forward, useful, retains compatibility with C, standardizes existing practice. Ship it.
</ul>
P2324r1 Labels at the end of compound statements (C compatibility) {#P2324r1}
-------
* [[P2324r1]]
* <a href="https://github.com/cplusplus/papers/issues/1006">GitHub issue</a>
* **Highlight:** Labels are allowed at the end of compound statements in C, but not C++. For example `int main() { invalid_cpp: }`. This paper rectifies this minor divergence.
* **🗳 Poll:** Forward P2324r1 "Labels at the end of compound statements (C compatibility)" to Core for C++23.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>20</td><td>11</td><td>3</td><td>0</td><td>0</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 11</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Favor:** Improves compatibility with C23, removes an IMHO unnecessary restriction.
</ul>
P2071r1 Named universal character escapes {#P2071r1}
-------
* [[P2071r1]]
* <a href="https://github.com/cplusplus/papers/issues/798">GitHub issue</a>
* **Highlight:** C++ programmers have been able to portably use characters outside of the basic source character set in character and string literals using *universal-character-names* since C++ was standardized. For example the following UTF-8 string literal: `u8"\u0100\u0300"`. This proposal enables the above literal to be written using Unicode assigned names instead of Unicode code point values. The following is equivalent to the preceding C++ example `u8"\N{LATIN CAPITAL LETTER A WITH MACRON}\N{COMBINING GRAVE ACCENT}"`.
* **🗳 Poll:** Forward P2071r1 "Named universal character escapes" to Core for C++23.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>12</td><td>14</td><td>3</td><td>3</td><td>1</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 12</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Strong Favor:** Avoid specifying magic values in code.
<li>**Favor:** One would hope that many `\u` escape sequences are accompanied by comments explaining the character being selected. It is plainly superior to have the compiler map from the human-readable concept to the numeric one, just as it does for machine code. The size cost in the implementation appears to be acceptable.
<li>**Favor:** Unicode compatibility is extremely important, and this feature makes it easier for users to incorporate Unicode into their applications. I find the concerns about increased binary size of the compiler to be extremely underwhelming.
<li>**Neutral:** While I can see the usefulness, I'm not sure Unicode character escapes is something that will be used often enough to make up for the need of a dictionary in the compiler. Neutral simply because it is not an overly large dictionary.
<li>**Against:** Concern about the compiler space overhead.
<li>**Strong Against:** Having to add a few hundred KB to C++ tools (which are often only a few MB) is way too high of a cost for the relatively minor convenience this feature offers.
</ul>
P2295r5 Support for UTF-8 as a portable source file encoding {#P2295r5}
-------
* [[P2295r5]]
* <a href="https://github.com/cplusplus/papers/issues/985">GitHub issue</a>
* **Highlight:** The set of source file character sets is currently implementation-defined. This paper mandates that C++ compilers must accept UTF-8 as an input format. How the source file encoding is detected, which other input formats are accepted, and what the storage media is (e.g. files), remain implementation-defined.
* **🗳 Poll:** Forward P2295r5 "Support for UTF-8 as a portable source file encoding" to Core for C++23.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>20</td><td>9</td><td>3</td><td>0</td><td>0</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 13</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Strong Favor:** This is the most important change we can make for Unicode support in C++. It allows for string literals to seamlessly incorporate UTF-8 code sequences without worrying about how those sequences will be interpreted across varying compilers.
</ul>
P2290r2 Delimited escape sequences {#P2290r2}
-------
* [[P2290r2]]
* <a href="https://github.com/cplusplus/papers/issues/983">GitHub issue</a>
* **Highlight:** Add an additional, clearly delimited syntax for octal, hexadecimal and universal character name escape sequences. The new syntaxes `\u{}`, `\o{}`, `\x{}` are usable in places where `\u`, `\x`, `\nnn` currently are.
* **🗳 Poll:** Forward P2290r2 "Delimited escape sequences" to Core for C++23.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>9</td><td>15</td><td>3</td><td>1</td><td>1</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 16</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Strong Favor:** The current alternative (write every character as a 3-digit octal number) is user-hostile. This is a welcome addition.
<li>**Neutral:** It's not clear that having yet another syntax is preferable to having our current less ergonomic forms, especially given that `\U00012345` is not much longer than `\u{12345}` and `\u1234` isn't greedy and is shorter than almost all `\u{...}` values. The greedy `\x` is a bit more trouble, but it's very common to have "binary" escapes in long sequences; code generators that might need to generate a mixture of escapes and ordinary characters can of course handle the awkwardness in just one place.
<li>**Against:** `\u{...}` saves characters and no longer asks users to learn both `\u` and `\U`, so people will use them. The other two are unlikely to be popular. `{0x2c, 0x10, 0}` is about the same length and more straightforward comparing to `"\x{2c}\x{10}"`. For the beneficial parts, this paper seems unnecessary if we further extend on top of P2071 `\N{U+10034}`.
<li>**Strong Against:** Unnecessary
</ul>
P2362r3 Remove non-encodable wide character literals and multicharacter wide character literals {#P2362r3}
-------
* [[P2362r3]]
* <a href="https://github.com/cplusplus/papers/issues/1036">GitHub issue</a>
* **Highlight:** C++ currently permits writing a wide character literal with multiple characters or characters that cannot fit into a single `wchar_t` codeunit. This paper makes these literals ill-formed.
* **🗳 Poll:** Forward P2362r3 "Remove non-encodable wide character literals and multicharacter wide character literals" to Core for C++23.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>14</td><td>12</td><td>2</td><td>1</td><td>0</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 16</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
h <li>**Favor:** Multicharacter literals in general are not usefully standardized, and the wide-character variants have no practical application, not least because they suffer from the inadequate wchar_t on Windows. That the change is a simplification to one of the ugliest parts of the standard is a bonus.
<li>**Favor:** It's hard to imagine that any use of these sequences is not a bug.
<li>**Against:** I don't know what this paper **enables,** and the issue still looks like a QoI to me.
</ul>
P2348r2 Whitespaces Wording Revamp {#P2348r2}
-------
* [[P2348r2]]
* <a href="https://github.com/cplusplus/papers/issues/1027">GitHub issue</a>
* **Highlight:** Clarify what constitutes a new-line and a whitespace, using Unicode terminology.
* **🗳 Poll:** Forward P2348r2 "Whitespaces Wording Revamp" to Core for C++23.
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td>10</td><td>17</td><td>2</td><td>0</td><td>0</td></tr>
<tr><td colspan=5><strong>Abstain:</strong> 16</td></tr>
</table>
<br><strong>Poll outcome:</strong>✅ consensus
<strong>Salient comments:</strong>
<ul>
<li>**Strong Favor:** This sort of modernization is welcome, if only so that we can stop spending time thinking about these issues informally. Removing silly things like IFNDR for comments is plainly an improvement. Consistency with other practical languages is more important than following Unicode's suggestions for plain text when there (unfortunately) is disagreement.
</ul>
<!--
-------
* [[]]
* <a href="">GitHub issue</a>
* **Highlight:**
* **🗳 Poll:** Forward
<strong>Poll votes:</strong>
<table>
<thead><tr><td>SF</td><td>F</td><td>N</td><td>A</td><td>SA</td></tr></thead>
<tr><td></td><td></td><td></td><td></td><td></td></tr>
<tr><td colspan=5><strong>Abstain:</strong> </td></tr>
</table>
<br><strong>Poll outcome:</strong>
<strong>Salient comments:</strong>
<ul>
<li>**:**
</ul>
-->
Polling Process {#process}
===============
For each poll, participants are asked to vote one of:
* Strongly in favor
* In favor
* Neutral
* Against
* Strongly against
Participants also have the option to abstain from voting on a particular poll. They are 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>
<li>2021-01-20 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/Minutes-2021-01-20">Final polls preparation</a>
<li>2021-01-28 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-01-28">P2012 Fix the range‐based for loop</a>
<li>2021-02-03 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-02-03">P2280 Using unknown references in constant expressions</a>
<li>2021-02-11 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-02-11">P1974 Non-transient constexpr allocation using <code>propconst</code></a>
<li>2021-02-17 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-02-17">P2242 Non-literal variables (and labels and <code>goto</code>s) in <code>constexpr</code> functions</a>
<li>2021-02-25 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-02-25">P1371 pattern matching: implementation experience</a> pattern matching now has fairly capable prototype implementation and in this session it will be both demonstrated and described. Bruno, the core implementer, will also field any implementation related questions surrounding the proposal. See the <a href="https://godbolt.org/z/fdd5j4">Godbolt demo</a>.
<li>2021-03-02 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EvolutionJoint-2021-03-02">P2279R0 We need a language mechanism for customization points</a> joint EWG+LEWG session
<li>2021-03-11 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-03-11">P2285 Are default function arguments in the immediate context?</a>
<li>2021-03-17 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-03-17">P2266 Simpler implicit move</a>
<li>2021-03-25 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-03-25">P2128 Multidimensional subscript operator</a>
<li>2021-03-31 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-03-31">P2036 Changing scope for lambda trailing-return-type, and P2287 Designated-initializers for base classes</a>
<li>2021-04-08 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-04-08">Pattern matching identifier patterns syntax: <code>let</code> vs <code>auto</code> vs none</a> Introducing bindings inside pattern matching: Unqualified identifier within pattern matching must have well defined meaning. Published version of the paper (P1371R4) proposed using case keyword to disambiguate names between identifier expressions and introducing named binding. This direction raised some concerns within committee and authors want to propose another way of resolving the ambiguity. After the presentation authors would like to have a poll to secure committee approval on the proposed direction.
<li>2021-04-22 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-04-22">P2334 Add support for preprocessing directives <code>elifdef</code> and <code>elifndef</code>, and P2246 Character encoding of diagnostic text</a>
<li>2021-04-28 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-04-28">Final discussion of the polls, and P2066 Suggested draft TS for C++ Extensions for Minimal Transactional Memory</a>
<li>2021-05-06 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-05-06">P2314 Character sets and encodings, and quick review of r2 for P2280 Using unknown references in constant expressions</a>
<li>2021-05-12 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-05-12">P2255 A type trait to detect reference binding to temporary</a>
<li>2021-05-20 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-05-20">P2025 Guaranteed copy elision for named return objects</a>
<li>2021-05-26 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-05-26">P2041 Deleting variable templates</a>
<li>2021-06-03 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-06-03">P1967 <code>#embed</code> — a simple, scannable preprocessor-based resource acquisition method</a>
<li>2021-06-14 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/P2138">Joint session with LEWG on P2138 Rules of Design <code><=></code> Specification engagement</a>
<li>2021-06-23 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-06-23">P1701 Inline Namespaces: Fragility Bites</a>
<li>2021-07-01 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-07-01">P2360R0 Extend init-statement to allow alias-declaration, and P2290 Delimited escape sequences, and P2316 Consistent character literal encoding</a>
<li>2021-07-07 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-07-07">P2392R0 Pattern matching using <code>is</code> and <code>as</code></a>
<li>2021-07-21 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-07-21">P2350 constexpr class</a>
<li>2021-07-29 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-07-29">P1169 <code>static operator()</code></a>
<li>2021-08-04 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-08-04">P2347 Argument type deduction for non-trailing parameter packs</a>
<li>2021-08-12 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-08-12">P2355 Postfix fold expressions</a>
<li>2021-08-26 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-08-26">P2295 Support for UTF-8 as a portable source file encoding and P2362 Remove non-encodable wide character literals and multicharacter wide character literals</a>
<li>2021-09-01 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-09-01">P2414R1 Pointer lifetime-end zap proposed solutions</a>
<li>2021-09-15 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-09-15">P2327 De-deprecating volatile compound assignment</a>
<li>2021-09-23 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-09-23">P2277 Packs outside of Templates</a>
<li>2021-09-29 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-09-29">P2012 Fix the range-based for loop</a>
<li>2021-10-07 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-10-07">P2280 Using unknown pointers and references in constant expressions && P2266 Simpler implicit move</a>
<li>2021-10-13 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-10-13">P2448 Relaxing some <code>constexpr</code> restrictions && P2350 <code>constexpr</code> class</a>
<li>2021-10-21 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-10-21">P1467 extended floating-point</a>
<li>2021-10-27 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-10-27">P2437 support for <code>#warning</code></a>
<li>2021-11-04 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-11-04">P1494 Partial program correctness</a>
<li>2021-11-10 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-11-10">P2348 Whitespaces Wording Revamp && P2071 Named universal character escapes</a>
<li>2021-12-02 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-12-02">P2324 Labels at the end of compound statements && P114R5 Portable assumptions</a>
<li>2021-12-08 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-12-08">P1705 Enumerating Core Undefined Behavior (short paper, unlikely that there's content for EWG, let SG12 send to CWG) && P2468R0 The Equality Operator You Are Looking For</a>
<li>2021-12-16 <a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-12-16">P1467R7 Extended floating-point types and standard names</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 polling periods 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>
<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>[[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>
<p><a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-09-23">Notes 2021-09-23</a>: mark CWG2261 as Not A Defect, the example is now clearly ill-formed thanks to p1787, if we want to change this then we’d need a paper.
<pre>
| SF | F | N | A | SA |
| 3 | 8 | 3 | 0 | 0 |
</pre></p>
</td>
<td valign="top">
<p>NAD</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><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>
<p><a href="https://wiki.edg.com/bin/view/Wg21telecons2021/EWG-2021-09-23">Notes 2021-09-23</a>: POLL: in a new world with modules, inline isn’t merely an ODR tool. We therefore believe that CWG2270 is Not a Defect.
<pre>
| SF | F | N | A | SA |
| 0 | 10 | 2 | 0 | 0 |
</pre>
</td>
<td valign="top">
<p>NAD</p>
</td>
</tr>
<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>[[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>[[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>