On Tue, Jan 6, 2015 at 2:32 PM, Nelson, Clark <clark.nelson@intel.com> 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


> 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
#define TTP class

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.

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:


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.


> 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