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

N4051Allow 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_at_[hidden] Chair, CPLEX (C SG for parallel language extensions)
>
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features