<div dir="ltr"><div class="gmail_quote">On Mon, Dec 29, 2014 at 5:45 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">I notice that Richard is behind quite a few of the new features, for almost<br>none of which is any feature-test macro mentioned in the document. [shaking<br>head] Richard, Richard. :-)<br></blockquote><div><br></div><div>It&#39;s official, I&#39;m a terrible person. Apologies.</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">On Tue, Dec 30, 2014 at 9:54 AM, 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></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; For N3928 Extending static_assert why not just bump up the date on __cpp_static_assert?<br>
<br>
</span>Yeah, that&#39;s definitely worth considering. The change is a pretty minor<br>
tweak. (The recommendations I included for this were the ones provided<br>
in N3928 -- thanks, Walter.)</blockquote><div><br></div><div>Strongly agreed. This is a poster child for why we have version numbers on our feature macros.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; We could bump the date on __cpp_unicode_literals for - Scartch that - that&#39;s for strings.<br>
&gt; Just __cpp_utf8_char_literals I think.<br>
<br>
</span>Noted, thanks.</blockquote><div><br></div><div>I don&#39;t think we need or want a new macro name here. If I had a time machine, I&#39;d say:</div><div><br></div><div>__cpp_unicode_literals == 200704 means &quot;unicode character literals&quot;</div><div>__cpp_unicode_literals == 200710 means &quot;unicode character and string literals&quot;</div><div>__cpp_unicode_literals == 201411 means &quot;unicode character and string literals including u8 char literals&quot;</div><div><br></div><div>This slightly changes a previously-published recommendation, in that simply testing whether __cpp_unicode_literals is defined would no longer suffice to detect unicode string literal support, so I&#39;m happy to drop the first line. (I don&#39;t expect any vendor will ever ship an implementation that sets __cpp_unicode_literals to 200704, so it seems academic, and I&#39;m not too worried about including it.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
&gt; N4295 - Folding expressions: __cpp_parameter_pack_sorcery, __cpp_fold_expressions is probably better.<br>
<br>
</span>Interesting. Richard, for my curiosity, can you explain why the title of<br>
the document doesn&#39;t match the terminology used in the document?</blockquote><div><br></div><div>The paper had its name before we had decided on the name of the grammar term and the heading of the subclause in the standard. In the title, &quot;folding&quot; is being used as a verb rather than an adjective (think &quot;a paper on folding expressions over an arbitrary binary operator&quot;). The feature is called &quot;fold expressions&quot; within the standard text; I think __cpp_fold_expressions is the best name here.<br></div><div><br></div><div>(If I had my time machine, I&#39;d probably remove the &quot;ing&quot; from the title, at least in the wording paper, for clarity.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
&gt; N4266 - Attributes for namespaces and enumerators.  They really are sort of two different things:<br>
<br>
&gt; __cpp_namespace_attributes 201411<br>
&gt; __cpp_enumerator_attributes 201411<br>
<br>
</span>Hmm. It could be argued that each attribute that can appertain to a<br>
namespace or enumerator is a distinct thing. Today there is only one such<br>
attribute: deprecated. We could even consider bumping the value of<br>
__cpp_has_attribute(deprecated).</blockquote><div><br></div><div>I like both new macros. I don&#39;t think we need to change the value of __cpp_has_attribute(deprecated) unless we&#39;re worried that an implementation might ship the syntax support for namespace attributes and enumerator attributes but not allow the [[deprecated]] attribute to appertain to them.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OK. I have another question about this one. It mentions that the new<br>
declarations are available by including any of an even dozen headers. Does<br>
that mean that our recommendations should specify this macro as being<br>
defined by all of those headers?</blockquote><div><br></div><div>Yes, I think so. I would imagine every implementation does this in practice by using a helper header, so I think we&#39;d be frustrating both our users and our implementors if we didn&#39;t make the provision of macros and declarations line up.</div></div></div></div>