On Tue, Jan 6, 2015 at 2:32 PM, Nelson, Clark <clark.nelson_at_[hidden]>
wrote:

> > Finally looking at
> > N4258: Cleaning-up noexcept in the Library
> > The only thing I can think of that would be helpful is
> > __cpp_lib_allocator_is_always_equal
>
> The really interesting question about this, like
> __cpp_lib_nonmember_container_access, is exactly which headers are
> supposed to
> define it? (I'm almost inclined simply to assume that the answer will be
> the
> same here, instead of actually investigating it myself.)
>
> > In my last email I was thinking out loud and maybe it looked chaotic to
> me this morning.
> > I would like to summarize my favored approaches:
>
> Thanks so much for this; I was trying to sort out proposals from musings.
> :-)
>
> > N4267 (u8 character literals)
> > __cpp_unicode_characters 201411
>
> For the time being I am leaving in __cpp_unicode_literals as a possibility;
> we'll sort that out when we have a meeting.
>
> > N4190 (removing old stuff)
> > __cpp_lib_remove_auto_ptr 201411
> > __cpp_lib_remove_random_shuffle 201411
> > __cpp_lib_remove_deprecated_functionals 201411
> > __cpp_lib_remove_deprecated_bind 201411
> > These would get date bumps if/when std::not_fun etc. or std::bind is
> removed.
> > I am slightly annoyed that the fist two don't have _deprecated_ but they
> look nice to me as they are.
>
> Personally, I prefer the first two, and am more annoyed that we seem to
> need
> to use "deprecated" in the latter two; to me that feels like a cop-out,
> whereas it should be redundant with "remove".
>
> In any event, we definitely need feedback from STL (and probably others)
> about
> the granularity of the functional stuff.
>
> My only other comment is that I prefer "removed" to "remove". I have taken
> the liberty of entering them that way into the draft SD-6.
>
> > N4279 - Improved insertion interface for unique-key maps
> > __cpp_lib_map_insertion 201411
> > __cpp_lib_unordered_map_insertion 201411
>
> Thanks.
>
> > N4051 Allow typename in a template template parameter
> > __cpp_typename_in_template_template_parm 201411
> > This may be too little to mess with.
>
> This is a really good question. The only way I could see this being used
> would be like so:
> #if __cpp_typename_in_template_template_parm
> #define TTP typename
> #else
> #define TTP class
> #endif
>
> with template template parameters declared like so:
> template<template<...> TTP X> ...
>
> Obviously, the interesting questions are, what sort of spelling might
> actually be used for the name of what I have called "TTP", and would anyone
> actually bother to write code like this?


It really depends what we think feature test macros are for. Another
possible use is this:

#if !__cpp_typename_in_template_template_parm
#error You need a compiler supporting C++17 to build this code.
#endif

So, do we only care about feature-test macros that allow a program to use
the feature if present and reasonably fall back if not, or do we also care
about cases where the only reasonable response to a missing feature is to
cause an error (or fail a configure check or similar)? The latter case
covers this feature, trigraph removal, digit separators, and probably some
others, which should presumably be treated uniformly.

> N4268 - Allow constant evaluation for all non-type template arguments
> > __cpp_const_eval_of_non_type_template_args
>
> I have tweaked the spelling of this slightly:
> __cpp_const_eval_all_nontype_template_args


That seems quite verbose. How about:

  __cpp_nontype_template_arg_eval

Even then, I worry that the "eval" is missing the point. The change removes
a syntactic restriction as much as it introduces different semantics. I
wonder if simply

  __cpp_nontype_template_args == 201411

would be acceptable; I think that's my preferred spelling for this.

> N4230 - Nested namespace definition
> > __cpp_nested_namespace_definitions 201411
> > I like this better than __cpp_nested_namespaces that I had before.
>
> Thanks.
>
> > N3922 - New Rules for auto deduction from braced-init-list
> > __cpp_auto_deduction 200604 for C++11
> > __cpp_auto_deduction 201411 for C++17
> > This could be an alternate spelling of __cpp_return_type_deduction:
> > __cpp_auto_deduction 201304 for C++14
>
> I have added this to the table for C++17, but until we've had more
> discussion,
> I'm not going to do anything to the earlier recommendations.
>
> Another update attached; only two documents left with no proposed
> recommendation.


N4259: __cpp_lib_uncaught_exceptions
N4089: __cpp_lib_unique_ptr_array_conversions