<div dir="ltr"><div class="gmail_quote">On Mon, Dec 29, 2014 at 5:45 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">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's official, I'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"><<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>></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="">> For N3928 Extending static_assert why not just bump up the date on __cpp_static_assert?<br>
<br>
</span>Yeah, that'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="">> We could bump the date on __cpp_unicode_literals for - Scartch that - that's for strings.<br>
> Just __cpp_utf8_char_literals I think.<br>
<br>
</span>Noted, thanks.</blockquote><div><br></div><div>I don't think we need or want a new macro name here. If I had a time machine, I'd say:</div><div><br></div><div>__cpp_unicode_literals == 200704 means "unicode character literals"</div><div>__cpp_unicode_literals == 200710 means "unicode character and string literals"</div><div>__cpp_unicode_literals == 201411 means "unicode character and string literals including u8 char literals"</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'm happy to drop the first line. (I don't expect any vendor will ever ship an implementation that sets __cpp_unicode_literals to 200704, so it seems academic, and I'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="">
> 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'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, "folding" is being used as a verb rather than an adjective (think "a paper on folding expressions over an arbitrary binary operator"). The feature is called "fold expressions" 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'd probably remove the "ing" 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="">
> N4266 - Attributes for namespaces and enumerators. They really are sort of two different things:<br>
<br>
> __cpp_namespace_attributes 201411<br>
> __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't think we need to change the value of __cpp_has_attribute(deprecated) unless we'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'd be frustrating both our users and our implementors if we didn't make the provision of macros and declarations line up.</div></div></div></div>