<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">
Is there consensus that bumping the value is the right design for feature additions? I see value bumping as valuable when a design changes (e.g. the many iterations of move semantics, the changing rules around spaceship), but when there is a feature addition,
then there is the potential for implementors to do things in the "wrong" order.<br>
<br>
<br>
<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">
<span id="OutlookSignature">
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">
Get <a href="https://aka.ms/ghei36">Outlook for Android</a></div>
</span><br>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> features-bounces@open-std.org <features-bounces@open-std.org> on behalf of Barry Revzin <barry.revzin@gmail.com><br>
<b>Sent:</b> Wednesday, August 28, 2019 10:05:32 PM<br>
<b>To:</b> Features@open-std.org <Features@open-std.org><br>
<b>Subject:</b> [EXTERNAL] [SG10] Missing feature-test macros since 2017</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>Hey all,</div>
<div><br>
</div>
<div>I updated the SD-6 document on <a href="https://urldefense.com/v3/__http://isocpp.org__;!fqWJcnlTkjM!-5kdhq5U_HvJ_BHVqMUTJ18-Q-Pb7kG7xv3XtLAk_hVdPs7_0ReOKreaG1Jj$">
isocpp.org</a>: <a href="https://urldefense.com/v3/__https://wg21.link/sd6__;!fqWJcnlTkjM!-5kdhq5U_HvJ_BHVqMUTJ18-Q-Pb7kG7xv3XtLAk_hVdPs7_0ReOKk5A5zKY$">
https://wg21.link/sd6</a>. I'm still having some CSS woes, but otherwise I updated the original document with the feature-test macros that have been adopted since it was first written, and organized the table by macro so that it's easy to see the history of
values (e.g. for CTAD: <a href="https://urldefense.com/v3/__https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations*__cpp_deduction_guides__;Iw!fqWJcnlTkjM!-5kdhq5U_HvJ_BHVqMUTJ18-Q-Pb7kG7xv3XtLAk_hVdPs7_0ReOKhzMIJNd$">
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#__cpp_deduction_guides</a>). Please let me know if anything is wrong there, or missing, or generally could be improved.<br>
</div>
<div><br>
</div>
<div>Also, I went through the Straw Polls pages to see if we missed any macros and made the following list. I tried to be as liberal as possible in determining whether people would attempt to write code in both the old and new way, so as to prefer to produce
a list with some things we could reject rather than miss more things... so I expect several of these may not actually need a macro. Several of them didn't (like "down with typename" - presumably you would just... write typename).<br>
</div>
<div><br>
</div>
<div>Let me know what you think. What belongs, what doesn't belong, any opinions would be very helpful. I'm intending to write a paper for Belfast with whatever we all decide is actually missing:<br>
<br>
Toronto 2017 (201707)<br>
- Designated Initializers (P0329R4)<br>
- Familiar syntax for generic lambdas (P0428R2)<br>
- make_shared for arrays (P0674R1)<br>
<br>
Albuquerque 2017 (201711)<br>
- Range-for with initializer (P0614R1, bump __cpp_range_based_for?)<br>
- ADL and function templates (P0846R0)<br>
- Default constructible and assignable lambdas (P0624R2)<br>
- Lambdas in unevaluated contexts (P0315R4)<br>
- remove_cvref (P0550R2)<br>
- syncbuf (P0053R7)<br>
- to_address (P0653R2)<br>
- constexpr for complex (P0415R1)<br>
- atomic shared_ptr (P0718R2)<br>
- floating point atomic (P0020R6)<br>
- starts_with/ends_with (P0457R2)<br>
<br>
Jacksonville 2018 (201803)<br>
- Pack expansion in lambda init-capture (P0780R2)<br>
- Symmetry for <=> (P0905R1, should bump __cpp_impl_three_way_comparison?)<br>
- Comparing unordered containers (P0809R0)<br>
- <chrono> for calendars and timezones (P0355R7)<br>
- Manipulators for synchronized buffered ostream (P0753R2, should bump<br>
whatever syncbuf adds)<br>
- span (P0122R7)<br>
<br>
Rapperswil 2018 (201806)<br>
- Virtual calls in constexpr (P1064R0)<br>
- contains (P0458R2)<br>
- constexpr array comparison? (P1023R0)<br>
- shift algorithms (P0769R2)<br>
- identity (P0887R1)<br>
- is_nothrow_convertible (P0758R1)<br>
- integral power of 2 functions (P0556R3)<br>
<br>
San Diego 2018 (201811)<br>
- things that bump constexpr (try/catch P1002R1, dynamic_cast, polymorphic typeid P1327R1, and change active member of union P1330R0)
<br>
- immediate functions (P1073R3)<br>
- optional/variant propogate triviality (P0602R4)<br>
- visit<R> (P0655R1)<br>
- constexpr pointer_traits (P1006R1, possibly with __cpp_lib_constexpr)<br>
- unwrap_ref_decay / unwrap_reference (P0318R1)<br>
- sane variant converting ctor (P0608R3)<br>
- assume_aligned (P1007R3)<br>
- smart pointer with default init (P1020R1)<br>
- should span be regular (P1085R2, just bump from the other span paper)<br>
<br>
Kona 2019 (201902)<br>
- extending structured bindings (P1091R3, P1381R1)<br>
- <=> != == (should bump both the class nttp macro, and the 3-way comparison macro)<br>
- polymorphic_allocator (P0339R6)<br>
- std:ssize (P1227R2)<br>
- more span things (P1024R3)<br>
<br>
Cologne 2019 (201907<br>
- mothership library paper introduces a new macro for no reason (P1614R2), should have just bumped __cpp_lib_three_way_comparison<br>
- efficient stringbuf (P0408R7)</div>
<div><br>
</div>
<div>Barry<br>
</div>
</div>
</div>
</body>
</html>