Subject: Re: [SG10] Updates to SD-6
From: Richard Smith (richard_at_[hidden])
Date: 2015-01-07 21:04:03
On Tue, Jan 6, 2015 at 2:32 PM, Nelson, Clark <clark.nelson_at_[hidden]>
> > 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
> 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
> > 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
> 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)
> 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:
#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:
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
> I'm not going to do anything to the earlier recommendations.
> Another update attached; only two documents left with no proposed
SG10 list run by herb.sutter at gmail.com