<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">&lt;<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>&gt;</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="">&gt; Finally looking at<br>
&gt; N4258: Cleaning-up noexcept in the Library<br>
&gt; The only thing I can think of that would be helpful is<br>
&gt; __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&#39;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>
&gt; In my last email I was thinking out loud and maybe it looked chaotic to me this morning.<br>
&gt; 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>
&gt; N4267 (u8 character literals)<br>
&gt;       __cpp_unicode_characters                201411<br>
<br>
</span>For the time being I am leaving in __cpp_unicode_literals as a possibility;<br>
we&#39;ll sort that out when we have a meeting.<br>
<span class=""><br>
&gt; N4190 (removing old stuff)<br>
&gt;       __cpp_lib_remove_auto_ptr               201411<br>
&gt;       __cpp_lib_remove_random_shuffle         201411<br>
&gt;       __cpp_lib_remove_deprecated_functionals 201411<br>
&gt;       __cpp_lib_remove_deprecated_bind        201411<br>
&gt; These would get date bumps if/when std::not_fun etc. or std::bind is removed.<br>
&gt; I am slightly annoyed that the fist two don&#39;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 &quot;deprecated&quot; in the latter two; to me that feels like a cop-out,<br>
whereas it should be redundant with &quot;remove&quot;.<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 &quot;removed&quot; to &quot;remove&quot;. I have taken<br>
the liberty of entering them that way into the draft SD-6.<br>
<span class=""><br>
&gt; N4279 - Improved insertion interface for unique-key maps<br>
&gt;       __cpp_lib_map_insertion                 201411<br>
&gt;       __cpp_lib_unordered_map_insertion       201411<br>
<br>
</span>Thanks.<br>
<span class=""><br>
&gt; N4051 Allow typename in a template template parameter<br>
&gt;       __cpp_typename_in_template_template_parm        201411<br>
&gt; 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&lt;template&lt;...&gt; TTP X&gt; ...<br>
<br>
Obviously, the interesting questions are, what sort of spelling might<br>
actually be used for the name of what I have called &quot;TTP&quot;, 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="">
&gt; N4268 - Allow constant evaluation for all non-type template arguments<br>
&gt; __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 &quot;eval&quot; 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&#39;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="">
&gt; N4230 - Nested namespace definition<br>
&gt;       __cpp_nested_namespace_definitions      201411<br>
&gt; I like this better than __cpp_nested_namespaces that I had before.<br>
<br>
</span>Thanks.<br>
<span class=""><br>
&gt; N3922 - New Rules for auto deduction from braced-init-list<br>
&gt;       __cpp_auto_deduction                    200604          for C++11<br>
&gt;       __cpp_auto_deduction                    201411          for C++17<br>
&gt; This could be an alternate spelling of __cpp_return_type_deduction:<br>
&gt;       __cpp_auto_deduction                    201304          for C++14<br>
<br>
</span>I have added this to the table for C++17, but until we&#39;ve had more discussion,<br>
I&#39;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>