<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 01/05/2015 04:29 PM, Nelson, Clark
wrote:<br>
</div>
<blockquote
cite="mid:38C37E44FD352B44ABFC58410B0790D07EB75F42@ORSMSX103.amr.corp.intel.com"
type="cite">
<pre wrap="">Here's an updated document.
Summarizing recent discussion:
With respect to N4267 (u8 character literals), we have now had three macro
name proposals:
__cpp_utf8_char_literals
__cpp_unicode_literals
__cpp_unicode_characters</pre>
</blockquote>
I think I'm responsible for all three :-(<br>
For what it's worth, my favorite is my last idea:<br>
to leave <br>
<pre wrap="">__cpp_unicode_literals
</pre>
alone (applying to strings)<br>
But just bump the date on<br>
<pre>__cpp_unicode_characters</pre>
Nothing is removed. Nothing is added. I thought having separate
macros for strings and chars is really not that bad - not nearly
"bad" enough to remove anything in SD-6. It even makes some sense
to me to have two macros.<br>
<blockquote
cite="mid:38C37E44FD352B44ABFC58410B0790D07EB75F42@ORSMSX103.amr.corp.intel.com"
type="cite"> </blockquote>
<blockquote
cite="mid:38C37E44FD352B44ABFC58410B0790D07EB75F42@ORSMSX103.amr.corp.intel.com"
type="cite">
<pre wrap="">
The latter two, of course, update the value of a macro from C++11. I'm
inclined to guess that this is going to be considered a small enough tweak
that introducing a new macro name (such as the first) would not be
justified.
People have talked about how unfortunate it is that the C++11
recommendations use two different macro names for such closely related
features. So far, I have not interpreted this is an actual proposal to
change SD-6 -- it seems like noodling up to this point. But if someone
wants to produce a concrete proposal along these lines, we can certainly
consider it.
But I also want to point out that there are nine other C++17 papers for
which no proposal has yet been made.
For N4190 (removing old stuff) and N4258 (cleaning up noexcept), if no one
from SG10 makes a proposal pretty soon, I'm going to contact the authors to
see what kind of ideas they have.</pre>
</blockquote>
<tt>N4190 (removing old stuff) is pretty important for SD-6.</tt><tt><br>
</tt><tt>I think in general</tt><tt><br>
</tt><tt>__cpp_lib_remove_xxx</tt><tt><br>
</tt><tt>__cpp_remove_xxx</tt><tt> - (probably never used)<br>
</tt><tt><br>
</tt><tt>So here are some ideas:</tt><tt><br>
</tt><tt>__cpp_lib_remove_auto_ptr</tt><tt><br>
</tt><tt>__cpp_lib_remove_random_shuffle</tt><tt><br>
</tt><tt>__cpp_lib_remove_mem_fun</tt><tt> - for both </tt><tt>mem_fun/mem_fun_ref</tt><tt><br>
</tt><tt>__cpp_lib_remove_nary_function</tt><tt> - for both </tt><tt>unary_function/binary_function<br>
__cpp_lib_remove_ptr_fun<br>
<br>
I'm not sure we need to separate all the old functional stuff - I
can imagine a library easily clobbering all these in one go.</tt><tt><br>
</tt><tt>On the other hand I couldn't think of a good generic
name...</tt><tt><br>
</tt><tt>__cpp_lib_remove_functionals_that_make_us_cry</tt><tt><br>
</tt><tt><br>
</tt><tt>If we could use the word _old_ (or _deprecated_) then</tt><tt><br>
</tt><tt>__cpp_lib_remove_old_functionals</tt><tt><br>
</tt><tt>could be given a date as fist the N4190 removals are
applied and then the date could be bumped as not[12] are removed.</tt><tt><br>
</tt><tt><br>
</tt><tt>__cpp_lib_remove_enumerated_bind?</tt><tt><br>
</tt><tt>__cpp_lib_remove_numbered_bind?</tt><tt><br>
</tt><tt><br>
</tt><tt>Using _old_ as above we could have</tt><br>
<tt>__cpp_lib_remove_old_bind<br>
That would also start with bind1st etc and then maybe later the
date is bumped if we remove bind.<br>
<br>
I think my favorite is </tt><br>
<tt>__cpp_lib_remove_deprecated_xxx<br>
<br>
</tt><tt></tt><tt><br>
</tt><tt>N4279 - Improved insertion interface for unique-key maps</tt><tt><br>
</tt><tt>__cpp_lib_map_insertion</tt><tt><br>
</tt><tt>Do we need a second for unordered? It would be safer to
assume library maintainers would not implement both these at the
same time.</tt><tt><br>
</tt><tt>__cpp_lib_unordered_map_insertion</tt>
<br>
<br>
<tt>N4051</tt><tt> Allow typename in a template template parameter</tt><tt><br>
</tt><tt>__cpp_typename_in_template_template_parm</tt><tt><br>
OTOH this may just be too small to worry about.<br>
</tt><tt><br>
</tt><tt>N4268 - Allow constant evaluation for all non-type template
arguments</tt><tt><br>
</tt><tt>__cpp_</tt><tt>const_eval_of_non_type_template_args</tt><tt><br>
</tt><tt><br>
</tt><tt>N4230 - Nested namespace definition</tt><tt><br>
</tt><tt>__cpp_nested_namespaces</tt><tt><br>
<br>
</tt><tt>__cpp_auto_deduction<br>
Give C++11 an old value for this as </tt><tt><tt>N3922 seeks to
change the rules for this very thing</tt>.<br>
Should C++14 should have gotten a date for function return type?
oops.<br>
Give C++17 a newer value for </tt><tt>N3922: New Rules for auto
deduction from braced-init-list<br>
<br>
That's my 2cents.<br>
<br>
</tt>
<blockquote
cite="mid:38C37E44FD352B44ABFC58410B0790D07EB75F42@ORSMSX103.amr.corp.intel.com"
type="cite">
<pre wrap="">
--
Clark Nelson Chair, PL22.16 (ANSI C++ standard committee)
Intel Corporation Chair, SG10 (C++ SG for feature-testing)
<a class="moz-txt-link-abbreviated" href="mailto:clark.nelson@intel.com">clark.nelson@intel.com</a> Chair, CPLEX (C SG for parallel language extensions)
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Features mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Features@isocpp.open-std.org">Features@isocpp.open-std.org</a>
<a class="moz-txt-link-freetext" href="http://www.open-std.org/mailman/listinfo/features">http://www.open-std.org/mailman/listinfo/features</a>
</pre>
</blockquote>
<br>
</body>
</html>