<div dir="ltr"><div dir="ltr">On Wed, 28 Aug 2019 at 20:05, Barry Revzin &lt;<a href="mailto:barry.revzin@gmail.com">barry.revzin@gmail.com</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hey all,</div><div><br></div><div>I updated the SD-6 document on <a href="http://isocpp.org" target="_blank">isocpp.org</a>: <a href="https://wg21.link/sd6" target="_blank">https://wg21.link/sd6</a>. I&#39;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&#39;s easy to see the history of values (e.g. for CTAD: <a href="https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#__cpp_deduction_guides" target="_blank">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&#39;t (like &quot;down with typename&quot; - presumably you would just... write typename).</div></div></blockquote><div><br></div><div>In the below, interpret &quot;Needs motivation&quot; as &quot;I can&#39;t off-hand think of a case where the conditionally using this feature would be beneficial, but maybe I&#39;m not being imaginative enough.&quot; For those, I&#39;d lean towards not adding a macro until / unless we have a concrete case that would benefit from them.</div><div><br></div><div>Similarly, interpret &quot;Not worthwhile&quot; as &quot;I do not think we should provide a macro for this because the incremental benefit of using this feature compared to using a workaround is too small.&quot;</div><div><br></div><div>I&#39;m considering only the core language changes for now.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Let me know what you think. What belongs, what doesn&#39;t belong, any opinions would be very helpful. I&#39;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></div></div></blockquote><div><br></div><div>Needs motivation</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- Familiar syntax for generic lambdas (P0428R2)<br></div></div></blockquote><div><br></div><div>Needs motivation</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- make_shared for arrays (P0674R1)<br><br>Albuquerque 2017 (201711)<br>- Range-for with initializer (P0614R1, bump __cpp_range_based_for?)<br></div></div></blockquote><div><br></div><div>Not worthwhile. (Maybe, *maybe*, you&#39;re writing a statement-like macro and can give it a better expansion if this feature is available, but I think you can rewrite &#39;for (decl; range)&#39; as &#39;switch (decl; 0) case 0: for(range)&#39; in any such case.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- ADL and function templates (P0846R0)<br></div></div></blockquote><div><br></div><div>Not worthwhile</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- Default constructible and assignable lambdas (P0624R2)<br></div></div></blockquote><div><br></div><div>Needs motivation</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- Lambdas in unevaluated contexts (P0315R4)<br></div></div></blockquote><div><br></div><div>Not worthwhile -- there is a fairly lightweight syntactic workaround for the absence of this feature</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- 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></div></div></blockquote><div><br></div><div>Leaning not worthwhile</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- Symmetry for &lt;=&gt; (P0905R1, should bump __cpp_impl_three_way_comparison?)<br></div></div></blockquote><div><br></div><div>Yes, we should have a feature test macro for this. Bumping the macro version seems reasonable in isolation, but we should look at the papers affecting &lt;=&gt; more holistically. I doubt we need anything more than the old macro version and a version meaning &quot;what we have in the C++20 CD&quot; -- tracking the path by which we reached that point isn&#39;t interesting if no-one has implemented a mid-way point.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- Comparing unordered containers (P0809R0)<br>- &lt;chrono&gt; 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></div></div></blockquote><div><br></div><div>Needs motivation</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- 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)
</div></div></blockquote><div><br></div><div>Needs motivation</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- immediate functions (P1073R3)<br></div></div></blockquote><div><br></div><div>Yes, I think we should have a macro for this. I think it&#39;s reasonable to write functions that are consteval in C++20 and constexpr in C++17 (things you really want to only evaluate at compile time, but for which you can&#39;t enforce that until C++20).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- optional/variant propogate triviality (P0602R4)<br>- visit&lt;R&gt; (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></div></div></blockquote><div><br></div><div>Needs motivation</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- &lt;=&gt; != == (should bump both the class nttp macro, and the 3-way comparison macro)<br></div></div></blockquote><div><br></div><div>Yes, we should do something about this. Per the above I think we should take a holistic view for &lt;=&gt; feature macros. Bumping the class type NTTP macro makes sense to me. Does any vendor advertise the old value yet?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>- polymorphic_allocator (P0339R6)<br>- std:ssize (P1227R2)<br>- more span things (P1024R3)<br>to me. <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>
_______________________________________________<br>
Features mailing list<br>
<a href="mailto:Features@isocpp.open-std.org" target="_blank">Features@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/features" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/features</a><br>
</blockquote></div></div>