-
Notifications
You must be signed in to change notification settings - Fork 0
/
2023_09_library_evolution_poll_outcomes.bs
662 lines (522 loc) · 24 KB
/
2023_09_library_evolution_poll_outcomes.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
<pre class='metadata'>
Title: 2023-09 Library Evolution Poll Outcomes
Shortname: P3020
Revision: 0
Status: P
Group: WG21
Editor: Inbal Levi - Library Evolution Chair, MPGC Services LTD, sinbal2l@gmail.com
Editor: Fabio Fracassi - Library Evolution Assistant Chair, CODE University of Applied Sciences, fabio@fracassi.de
Editor: Ben Craig - Library Evolution Assistant Chair, Raven, ben.craig@gmail.com
Editor: Billy Baker - Library Evolution Incubator Chair, NVIDIA, billy.baker.cpp@gmail.com
Editor: Nevin Liber - Library Evolution Incubator Assistant Chair and Admin Chair, Argonne National Laboratory, nevin@cplusplusguy.com
Editor: Corentin Jabot - Library Mailing List Review Manager, corentin.jabot@gmail.com
Audience: WG21
URL: https://wg21.link/P3020
!Source: <a href="https://github.com/inbal2l/wg21_library_evolution_polls_outcome_script/blob/main/2023_09_library_evolution_poll_outcomes.bs">GitHub</a>
Metadata Order: Editor, Source, Project, Audience
Markup Shorthands: markdown yes
Toggle Diffs: no
No Abstract: yes
Boilerplate: style-syntax-highlighting off
Default Biblio Display: direct
</pre>
# Introduction # {#introduction}
In 2023-09, the C++ Library Evolution group conducted a series of electronic decision polls [[P2972R0]].
This paper provides the results of those polls and summarizes the results.
In total, 25 people participated in the polls.
Some participants opted to not vote on some polls (Poll 2, Poll 8, Poll 12, Poll 13, had a low participation rate).
Thank you to everyone who participated, and to the proposal authors for all their hard work!
# Poll Outcomes # {#poll-outcomes}
* SF: Strongly Favor.
* WF: Weakly Favor.
* N: Neutral.
* WA: Weakly Against.
* SA: Strongly Against.
<table>
<tr>
<th>Poll
<th>SF
<th>WF
<th>N
<th>WA
<th>SA
<th>Outcome
<tr>
<td>
Poll 1: Send "[[P0843R9]] `inplace_vector`" to Library Working Group for C++26.
<td>12
<td>6
<td>2
<td>1
<td>1
<td>Consensus in favor.
<tr>
<td>
Poll 2: Send "[[P1068R9]] Vector API for random number generation" to Library Working Group for C++26.
<td>6
<td>7
<td>2
<td>0
<td>0
<td>Strong consensus in favor.
<tr>
<td>
Poll 3: Send "[[P2447R4]] `std::span` over an initializer list" to Library Working Group for C++26.
<td>7
<td>12
<td>0
<td>1
<td>1
<td>Consensus in favor.
<tr>
<td>
Poll 4: Send "[[P2591R4]] Concatenation of strings and string views" to Library Working Group for C++26.
<td>8
<td>11
<td>2
<td>1
<td>0
<td>Strong consensus in favor.
<tr>
<td>
Poll 5: Send "[[P2819R1]] Add tuple protocol to complex" to Library Working Group for C++26.
<td>14
<td>5
<td>1
<td>0
<td>0
<td>Strong consensus in favor.
<tr>
<td>
Poll 6: Send "[[P2821R4]] `span.at()`" to Library Working Group for C++26.
<td>9
<td>9
<td>2
<td>0
<td>2
<td>Consensus in favor.
<tr>
<td>
Poll 7: Send "[[P2833R1]] Freestanding Library: inout expected span" to Library Working Group for C++26.
<td>9
<td>8
<td>0
<td>0
<td>1
<td>Consensus in favor.
<tr>
<td>
Poll 8: Send "[[P2836R1]] `std::basic_const_iterator` should follow its underlying type's convertibility" to Library Working Group for C++26 and as a DR for C++23.
<td>11
<td>4
<td>0
<td>0
<td>0
<td>Strong consensus in favor.
<tr>
<td>
Poll 9: Send "[[P2868R1]] Remove Deprecated `std::allocator` Typedef From C++26" to Library Working Group for C++26.
<td>15
<td>5
<td>1
<td>0
<td>0
<td>Strong consensus in favor.
<tr>
<td>
Poll 10: Send "[[P2870R1]] Remove `basic_string::reserve()` From C++26" to Library Working Group for C++26.
<td>16
<td>3
<td>1
<td>1
<td>0
<td>Strong consensus in favor.
<tr>
<td>
Poll 11: Send "[[P2871R2]] Remove Deprecated Unicode Conversion Facets From C++26" to Library Working Group for C++26.
<td>13
<td>5
<td>1
<td>0
<td>0
<td>Strong consensus in favor.
<tr>
<td>
Poll 12: Send "[[P2905R2]] Runtime format strings" to Library Working Group for C++26 and as a DR for C++23.
<td>8
<td>8
<td>0
<td>0
<td>0
<td>Strong consensus in favor.
<tr>
<td>
Poll 13: Send "[[P2918R1]] Runtime format strings II" to Library Working Group for C++26.
<td>10
<td>4
<td>0
<td>2
<td>0
<td>Consensus in favor.
<tr>
<td>
Poll 14: Send "[[P2937R0]] Freestanding: Remove `strtok`" to Library Working Group for C++26.
<td>14
<td>4
<td>1
<td>0
<td>1
<td>Consensus in favor.
<tr>
<td>
Poll 15: Send "[[P2909R2]] Fix formatting of code units as integers (Dude, where’s my char?)" to Library Working Group for C++26 and as a DR for C++23.
<td>10
<td>8
<td>1
<td>0
<td>0
<td>Strong consensus in favor.
</table>
All the polls have consensus in favor, and will be forwarded to LWG.
# Selected Poll Comments # {#poll-comments}
For some of the comments, small parts were removed to anonymize.
## Poll 1: Send "[[P0843R9]] `inplace_vector`" to Library Working Group for C++26.
> This is a much needed vocabulary type. Now if only clump/small_vector would get in, then we'd have the complete set.
>
> — Strongly Favor
> This will be a useful addition although I feel the unsafe unchecked_push_back is insufficiently motivated based on benchmark data I've seen.
>
> — Strongly Favor
> This will be a useful addition although I feel the unsafe unchecked_push_back is insufficiently motivated based on benchmark data I've seen.
>
> — Weakly Favor
> This has some performance wins, and has the potential to add a resizable container to freestanding. I'm not thrilled with the unchecked calls from a security perspective, but they are far better than any of the other alternatives that have a chance to make it through the committee.
>
> — Weakly Favor
> Not sure this has had enough time to bake with the current wording. In particular, I believe that the "constexpr" part is currently unimplementable. But, LWG can always send it back if they agree.
>
> — Neutral
> I have some concerns regarding the error handling using exceptions, I think this paper requires more discussion
>
> — Weakly Against
> There is are very few scenarios in which bad_alloc is useful, one of them is by logging that the system has run out of memory.
> This paper nullifies that use cases by using bad_alloc as the exception it choose to throws, despite having nothing to do at all whatsoever with allocations. What is the point of having a complex hierarchy with bases classes and virtual methods if we are not going to use it correctly?
> The paper is not motivated, or rather the motivation for this paper ie supporting "environment which can't allocate" run afoul if its design "everything throws".
> In its current form, this is unlikely to be adopted by the game industry, the embedded community and other such constrained scenario.
> This type is therefore not fit for purpose.
>
> — Strongly Against
## Poll 2: Send "[[P1068R9]] Vector API for random number generation" to Library Working Group for C++26.
> The current one-element-at a-time interface pessimizes for both vectorization and parallelism. The paper's new interface corrects this, and also updates random number generation for C++ Ranges.
>
> — Strongly Favor
> It allows to make standard RNG faster even without low-level API if the quality of implementation is good. All the comments were address. Let's ship it!
>
> — Strongly Favor
> It is unclear to me whether we have implementation experience with exactly what's being proposed.
>
> — Weakly Favor
> I'm not yet convinced this is required by a large group of standard library users
>
> — Weakly Favour
> The wording looks dubious.
>
> — Neutral
## Poll 3: Send "[[P2447R4]] `std::span` over an initializer list" to Library Working Group for C++26.
> This is how it should be. Simple and expected behavior. While incomplete due to lack of guaranteed storage duration, this remains a step in the right direction.
>
> — Strongly Favor
> A initializer_list is essentially an immutable view over an fixed-size array. It seems like an oversight, that such a type wouldn’t be compatible with span.
>
> — Strongly Favor
> Every time a class is introduced, we should ask if a constructor from initializer_list makes sense or not, because adding them "after the fact" isn't always possible.
> As an argument type, span<const T> tries to replace a const vector<T>, and span should've had initializer_list construction from day one.
>
> — Strongly Favor
> It would be unfortunate to have to recommend the {{1,2,3}} syntax.
> The "void two(span<const int, 2>);" example is the most concerning incompatibility, but the general rule of initializer lists having runtime size is probably sufficient to avoid most confusion there.
>
> — Weakly Favor
> Breaking code is a little bit scary.
>
> — Weakly Favor
> This should not be a DR. I read the poll as if it isn't.
>
> — Weakly Favor
> The proposal does improve ergonomics. I'm a bit troubled by Section 4.2 ("The initializer_list ctor has high precedence"), in that it might discourage use of spans with compile-time sizes.
> On the other hand, there is a straightforward work-around. I wonder if we could solve this issue with a deduction guide that uses is_constant_evaluated() to determine whether calling .size() on the initializer_list results in a constant expression.
>
> — Weakly Favor
> Long time in waiting. There is some worry (hence the WF vote) about the cases of broken code, some of them not entirely contrived, but the benefit in both ease of writing and language consistency (and possibly even performance) clearly supersedes that.
>
> — Weakly Favor
> (...) I believe this feature doesn't bring so much value but on the other hand it introduces the breaking change and enables simpler use-cases like `std::span<const int> s{1,2,3};` which is error prone. Yeah, it's better than `std::span<int> s{1,2,3};` because of `const` and far better than `std::span s{1,2,3};` and doesn't work because deduction guides are not enabled for this use-case (fortunately) but still I believe danger for the user is more than the value since the applicability of the API is pretty narrow to me.
> On the other hand, we already have precedence in the standard where class initialized with temporary could immediately dangle. That's why I am weakly against. If this papers lands, so be it.
>
> — Weakly Against
> span is not a container and should not pretend to be one.
>
> — Strongly Against
## Poll 4: Send "[[P2591R4]] Concatenation of strings and string views" to Library Working Group for C++26.
> I’ve lost track of how many times I had to workaround these missing operators.
> While it may have been good intentioned to leave them out until we can come up with a lazy concatenation design, said feature never materialized and most probably shouldn’t be spelled as operator+ to begin with.
>
> — Strongly Favor
> This improves ergonomics and teachability.
> I am convinced by the arguments in Section 2.1 ("Why are those overloads missing in the first place?") why we should not delay adding this feature in the name of a nonexistent future proposal that could not be implemented fully anyway.
>
> — Strongly Favor
> I strongly believe that we should NOT be updating the __cpp_lib_string_view feature test macro, as we are making NO changes to string_view.
> We should add a new feature test macro instead (as none of the string ones look to be appropriate).
> (I would have voted SF instead of WF had it been a different feature test macro).
> Also, breaking user code is a little bit scary.
>
> — Weakly Favor
> Fixes an inconsistency in the library users have been complaining about (https://stackoverflow.com/q/44636549/471164).
>
> — Weakly Favor
> The proposal is the only reasonable interpretation of the syntax (and its discussion of the history adequately explains the omission as no longer relevant).
>
> — Weakly Favor
> Slightly hesitant due to the conversion-related risks. Overall though this is a highly missed addition, long time due.
> With this we will no longer have to guide devs to define string constants as constexpr string_view – but only if they don’t need them to be concatenated, in which case the unfortunate guidance becomes to use const std::string instead.
>
> — Weakly Favor
> It does fix a mistake, but unimportant.
>
> — Neutral
> Worried about the issues raised in Annex C;
> I'd prefer to see just the string + string_view overloads and not the additional overloads specified by [tab:string.op.plus.string_view.overloads].
>
> — Weakly Against
## Poll 5: Send "[[P2819R1]] Add tuple protocol to complex" to Library Working Group for C++26.
> This is how it should be. Simple and expected behavior. It is expected that new features will be consistent with the rest of the language.
> As such this is more a spec fix or completion of previous work.
>
> — Strongly Favor
> Good facility for std::complex. Assuming the comment on tuple-like concept is addressed I have no objections to that.
> Hopefully, one day we fix the tuple protocol to make it generic enough but it's a separate story.
>
> — Strongly Favor
> There was a concern about using hidden friends (although I'm not sure it was brought up formally):
> The main difference between having a normal function vs hidden friend is whether or not it is findable for types that are convertible to complex<T>.
>
> E.g. given:
> struct my_imaginary {
> double scale;
> operator std::complex<double>() const noexcept { return {0, scale}; }
> };
>
> Then the following will only work if std::complex<T> has non-hidden get() functions:
> my_imaginary x;
> auto [r, i] = x; // error: If get() is a hidden friend.
>
> — Strongly Favor
> It makes sense for complex to be decomposable but should it be tuple_like?
>
> — Weakly Favor
> Looks acceptable. I can't get excited about using structured bindings.
>
> — Weakly Favor
> Applying get<0>(c) to complex values may spoil redability of mathematically intensive code, but at the same the paper adds better integration with other standard facilities. Thus neutral.
>
> — Neutral
## Poll 6: Send "[[P2821R4]] `span.at()`" to Library Working Group for C++26.
> I've already used "span.at()" a few times in code bases, just so that I can be reminded by the compiler that it doesn't exist yet.
>
> — Strongly Favor
> While it doesn't bring much value to std::span itself it does bring the value to a generic code and it makes API more consistent.
> Since we can now add classes partially to freestanding I don't have any problems with adding this method.
>
> — Strongly Favor
> We can entertain lengthy discussions about how and why std::span differs from the original gls::span, but at this point we should simply strive for consistency.
>
> — Strongly Favor
> It is embarrassing not to have it. It is safe and consistent. We need more safe functions instead of unsafe ones.
>
> — Strongly Favor
> This addition makes span more consistent with vector. I also appreciate that the author has taken the time to address freestanding.
> However, I disagree that "a function that throws when the input is out of bounds" is necessarily "safer" than a function with a nontrivial precondition. I'm not an expert in functional safety, but I've heard such experts share my opinion.
> My concern only addresses this one motivation for the paper; making span consistent with vector justifies the paper in itself.
>
> — Weakly Favor
> So long as we're happy having classes have incomplete interfaces in freestanding, this is only reasonable based on consistency, since there's no cost to having the feature.
>
> — Weakly Favor
> Not convinced that this is worth adding.
>
> — Neutral
> This is extremely poorly motivated in my view.
> Throwing exception of developer error is not something we should encourage, and it certainly does not encourage safety.
> Consistency with past mistakes is also not a very convincing argument.
> Ask your local standard library implementer an harden build that terminates on out-of-bound. These things exist and they are great!
>
> — Strongly Against
> This is safety theatre (a term analogous to the well understood term "security theater").
> MISRA doesn't require usage of .at() and I don't see C++ engineers adopting .at() any time soon.
> If we want to reduce C++ vulnerabilities due to memory safety violations, we should attack that problem directly instead of making changes that make us feel good, but do nothing to solve our problems.
>
> — Strongly Against
## Poll 7: Send "[[P2833R1]] Freestanding Library: inout expected span" to Library Working Group for C++26.
> freestanding has needed some kind of error handling mechanism for awhile, so this will be a big win.
>
> — Strongly Favor
> This will aid span's adoption which is essential since it is a fundamental type.
>
> — Strongly Favor
> Would have been nice to have the freestanding features done in fewer papers to save time for LEWG.
>
> — Weakly Favor
> We don't use freestanding, but these additions seem reasonable and useful for those that do.
>
> — Weakly Favor
> The addition of these features to the freestanding subset should be non-controversial.
>
> — Weakly Favor
> I'm unconvinced that spending time on the freestanding dialect of C++ is in the interest of our users.
>
> — Strongly Against
## Poll 8: Send "[[P2836R1]] `std::basic_const_iterator` should follow its underlying type's convertibility" to Library Working Group for C++26 and as a DR for C++23.
> This fixes a deficiency in the current C++ Standard. I agree that this change should be considered library DR.
>
> — Strongly Favor
> We need to add uniformity, and "wrapper types" should behave as the wrapped type
>
> — Strongly Favor
> I like not breaking C++20 code
>
> — Weakly Favor
> I'm not a fan of the DR part.
>
> — Weakly Favor
> The proposed conversions could in theory produce undesired complications, but I haven't checked.
>
> — I do not want to participate in this poll
## Poll 9: Send "[[P2868R1]] Remove Deprecated `std::allocator` Typedef From C++26" to Library Working Group for C++26.
> Once a good idea, but now std::allocator is no longer necessary.
>
> — Strongly Favor
> Although implementations will likely leave these in, the purpose of deprecation is ultimately to remove things, and so this should be done.
>
> — Strongly Favor
> We must remove or control baggage if C++ is to grow, change and remain relevant.
>
> — Strongly Favor
> I’ll finger the elephant in the room: DRY violation. This is an attribute, so its single source of truth should be allocator_traits, it has no business getting itself duplicated anywhere else.
>
> — Weakly Favor
> We have experience with the removed members in std::allocator.
>
> — Weakly Favor
## Poll 10: Send "[[P2870R1]] Remove `basic_string::reserve()` From C++26" to Library Working Group for C++26.
> I’m not sure why this function even exists in the first place. The default parameter that was originally supplied looks like a design bug - especially as it was exclusive to basic_string.
> Given that we have a replacement since C++11 and it isn’t even functional anymore since C++20 I see no reason to retain this overload.
>
> — Strongly Favor
> Although implementations will likely leave these in, the purpose of deprecation is ultimately to remove things, and so this should be done.
>
> — Strongly Favor
> We must remove or control baggage if C++ is to grow, change and remain relevant.
>
> — Strongly Favor
> The real semantic change (which is justifiable) has already occurred. This is, if anything, helpfully alerting people to the fact.
>
> — Weakly Favor
> I’m worried about the reported lack of deprecation warnings, and about the paper missing any research into the amount of existing code which may be broken by this.
> I think straight up removal may surprise some users by providing them no immediate clue as to how to modify their code.
> Therefore the path forward should be one cycle in which this function is implemented via a static_assert(false) with a relevant error message, followed by complete removal only in the next cycle (C++29).
>
> — Weakly Against
## Poll 11: Send "[[P2871R2]] Remove Deprecated Unicode Conversion Facets From C++26" to Library Working Group for C++2
> Having these seems worse than having nothing.
>
> — Strongly Favor
> The implementation is broken in MSVC at one point anyway.
>
> — Strongly Favor
> Regularly removing deprecated functionality is a good practice.
>
> — Strongly Favor
> This feature has never fundamentally worked correctly. Deprecation and, now, removal even without replacement is appropriate.
>
> — Weakly Favor
> Due to lack of usage experience I can’t comment on these facets.
>
> — Neutral
## Poll 12: Send "[[P2905R2]] Runtime format strings" to Library Working Group for C++26 and as a DR for C++23.
> This is the right thing to do. We should also make this a DR for C++23. I can't think of any correct code that would be broken by doing so.
>
> — Strongly Favor
> Improves safety of a formatting API by preventing some lifetime issues.
>
> — Strongly Favor
> I'm not a fan of the DR part, but it seems more plausible here than in some other cases.
>
> — Weakly Favor
> Preventing dangling is great but it is concerning that we continue to retroactively modify std::format two standard cycles after the feature was initially added.
>
> — Weakly Favor
> Obviously being able to use such strings is valuable, but the change could easily be unfortunately invasive; I haven't tried to vet it independently.
>
> — I do not want to participate in this poll
## Poll 13: Send "[[P2918R1]] Runtime format strings II" to Library Working Group for C++26.
> This is a good idea. Separating this from P2905 (the safety fix alone) was also a good idea, so that P2905 could be made a DR, while P2918 can be introduced "normally" in C++26.
>
> — Strongly Favor
> A straight-forward extension to std::format that doesn’t require changing existing standards and enables to-date missing functionality.
>
> — Strongly Favor
> A very important addition to std::format that allows to explicitly opt out of compile-time checks instead of misusing type erased APIs.
>
> — Strongly Favor
> Has implementation and usage experience.
>
> — Strongly Favor
> The new API seems a bit confusing, but not enough to preclude the important functionality.
>
> — Weakly Favor
> Users expect to be able to use a std::string as the first argument of std::format.
> If we lack the language facilities to provide this, we should add them instead of spending time with unsatisfying workarounds.
>
> — Weakly Against
> Why not std::runtime_format(str, 42)
>
> — Weakly Against
## Poll 14: Send "[[P2937R0]] Freestanding: Remove `strtok`" to Library Working Group for C++26.
> One foot-gun less ... strtok should actually be removed from the entire standard library.
>
> — Strongly Favor
> This function should not only be removed from freestanding, it should be yanked from the standard library as a whole.
>
> — Strongly Favor
> Keep C++ freestanding in line with C freestanding.
>
> — Strongly Favor
> One could argue that strtok on freestanding should just not be thread-safe at all, but the fact that C doesn't expect it to be there tips the balance in favor of removing it. (Who uses it anyway?)
>
> — Weakly Favor
> Would have been nice to have the freestanding features done in fewer papers to save time for LEWG
>
> — Weakly Favor
> I'm unconvinced that spending time on the freestanding dialect of C++ is in the interest of our users.
>
> — Strongly Against
## Poll 15: Send "[[P2909R2]] Fix formatting of code units as integers (Dude, where’s my char?)" to Library Working Group for C++26 and as a DR for C++23.
> This feels like the right thing to do, even if it is a breaking change. It's important for Standard Library output to be consistent.
>
> — Strongly Favor
> Spec fixes should be done, especially when there is negligible breakage.
>
> — Strongly Favor
> Fixes a problematic behavior in formatting characters as integers and makes formatting consistent among platforms.
>
> — Strongly Favor
> Improved consistency is great but we are yet again retroactively changing the meaning of std::format.
>
> — Weakly Favor
> No one expects code units to actually be negative and relies on two's complement (and little real arithmetic) to make that never matter in practice.
>
> — Weakly Favor
> Runtime change in behavior of C++20 facilities makes me really nervous, even when the change in an improvement.
>
> — Neutral