On 01/05/2015 04:29 PM, Nelson, Clark wrote:
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
I think I'm responsible for all three :-(
For what it's worth, my favorite is my last idea:
to leave
__cpp_unicode_literals
alone (applying to strings)
But just bump the date on
__cpp_unicode_characters
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.

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.
N4190 (removing old stuff) is pretty important for SD-6.
I think in general
__cpp_lib_remove_xxx
__cpp_remove_xxx - (probably never used)

So here are some ideas:
__cpp_lib_remove_auto_ptr
__cpp_lib_remove_random_shuffle
__cpp_lib_remove_mem_fun - for both mem_fun/mem_fun_ref
__cpp_lib_remove_nary_function - for both unary_function/binary_function
__cpp_lib_remove_ptr_fun

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.

On the other hand I couldn't think of a good generic name...
__cpp_lib_remove_functionals_that_make_us_cry

If we could use the word _old_ (or _deprecated_) then
__cpp_lib_remove_old_functionals
could be given a date as fist the N4190 removals are applied and then the date could be bumped as not[12] are removed.

__cpp_lib_remove_enumerated_bind?
__cpp_lib_remove_numbered_bind?

Using _old_ as above we could have
__cpp_lib_remove_old_bind
That would also start with bind1st etc and then maybe later the date is bumped if we remove bind.

I think my favorite is

__cpp_lib_remove_deprecated_xxx


N4279 - Improved insertion interface for unique-key maps
__cpp_lib_map_insertion
Do we need a second for unordered? It would be safer to assume library maintainers would not implement both these at the same time.
__cpp_lib_unordered_map_insertion

N4051 Allow typename in a template template parameter
__cpp_typename_in_template_template_parm
OTOH this may just be too small to worry about.

N4268 - Allow constant evaluation for all non-type template arguments
__cpp_const_eval_of_non_type_template_args

N4230 - Nested namespace definition
__cpp_nested_namespaces

__cpp_auto_deduction
Give C++11 an old value for this as
N3922 seeks to change the rules for this very thing.
Should C++14 should have gotten a date for function return type?  oops.
Give C++17 a newer value for
N3922: New Rules for auto deduction from braced-init-list

That's my 2cents.


--
Clark Nelson            Chair, PL22.16 (ANSI C++ standard committee)
Intel Corporation       Chair, SG10 (C++ SG for feature-testing)
clark.nelson@intel.com  Chair, CPLEX (C SG for parallel language extensions)


_______________________________________________
Features mailing list
Features@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/features