<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 6, 2015 at 2:32 PM, Nelson, Clark <span dir="ltr"><<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> Finally looking at<br>
> N4258: Cleaning-up noexcept in the Library<br>
> The only thing I can think of that would be helpful is<br>
> __cpp_lib_allocator_is_always_equal<br>
<br>
</span>The really interesting question about this, like<br>
__cpp_lib_nonmember_container_access, is exactly which headers are supposed to<br>
define it? (I'm almost inclined simply to assume that the answer will be the<br>
same here, instead of actually investigating it myself.)<br>
<span class=""><br>
> In my last email I was thinking out loud and maybe it looked chaotic to me this morning.<br>
> I would like to summarize my favored approaches:<br>
<br>
</span>Thanks so much for this; I was trying to sort out proposals from musings. :-)<br>
<span class=""><br>
> N4267 (u8 character literals)<br>
> __cpp_unicode_characters 201411<br>
<br>
</span>For the time being I am leaving in __cpp_unicode_literals as a possibility;<br>
we'll sort that out when we have a meeting.<br>
<span class=""><br>
> N4190 (removing old stuff)<br>
> __cpp_lib_remove_auto_ptr 201411<br>
> __cpp_lib_remove_random_shuffle 201411<br>
> __cpp_lib_remove_deprecated_functionals 201411<br>
> __cpp_lib_remove_deprecated_bind 201411<br>
> These would get date bumps if/when std::not_fun etc. or std::bind is removed.<br>
> I am slightly annoyed that the fist two don't have _deprecated_ but they look nice to me as they are.<br>
<br>
</span>Personally, I prefer the first two, and am more annoyed that we seem to need<br>
to use "deprecated" in the latter two; to me that feels like a cop-out,<br>
whereas it should be redundant with "remove".<br>
<br>
In any event, we definitely need feedback from STL (and probably others) about<br>
the granularity of the functional stuff.<br>
<br>
My only other comment is that I prefer "removed" to "remove". I have taken<br>
the liberty of entering them that way into the draft SD-6.<br>
<span class=""><br>
> N4279 - Improved insertion interface for unique-key maps<br>
> __cpp_lib_map_insertion 201411<br>
> __cpp_lib_unordered_map_insertion 201411<br>
<br>
</span>Thanks.<br>
<span class=""><br>
> N4051 Allow typename in a template template parameter<br>
> __cpp_typename_in_template_template_parm 201411<br>
> This may be too little to mess with.<br>
<br>
</span>This is a really good question. The only way I could see this being used<br>
would be like so:<br>
#if __cpp_typename_in_template_template_parm<br>
#define TTP typename<br>
#else<br>
#define TTP class<br>
#endif<br>
<br>
with template template parameters declared like so:<br>
template<template<...> TTP X> ...<br>
<br>
Obviously, the interesting questions are, what sort of spelling might<br>
actually be used for the name of what I have called "TTP", and would anyone<br>
actually bother to write code like this?</blockquote><div><br></div><div>It really depends what we think feature test macros are for. Another possible use is this:</div><div><br></div><div>#if !__cpp_typename_in_template_template_parm</div><div>#error You need a compiler supporting C++17 to build this code.</div><div>#endif</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> N4268 - Allow constant evaluation for all non-type template arguments<br>
> __cpp_const_eval_of_non_type_template_args<br>
<br>
</span>I have tweaked the spelling of this slightly: __cpp_const_eval_all_nontype_template_args</blockquote><div><br></div><div>That seems quite verbose. How about:</div><div><br></div><div> __cpp_nontype_template_arg_eval</div><div><br></div><div>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</div><div><br></div><div> __cpp_nontype_template_args == 201411</div><div><br></div><div>would be acceptable; I think that's my preferred spelling for this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> N4230 - Nested namespace definition<br>
> __cpp_nested_namespace_definitions 201411<br>
> I like this better than __cpp_nested_namespaces that I had before.<br>
<br>
</span>Thanks.<br>
<span class=""><br>
> N3922 - New Rules for auto deduction from braced-init-list<br>
> __cpp_auto_deduction 200604 for C++11<br>
> __cpp_auto_deduction 201411 for C++17<br>
> This could be an alternate spelling of __cpp_return_type_deduction:<br>
> __cpp_auto_deduction 201304 for C++14<br>
<br>
</span>I have added this to the table for C++17, but until we've had more discussion,<br>
I'm not going to do anything to the earlier recommendations.<br>
<br>
Another update attached; only two documents left with no proposed recommendation.</blockquote><div><br></div><div>N4259: __cpp_lib_uncaught_exceptions</div><div>N4089: __cpp_lib_unique_ptr_array_conversions</div></div></div></div>