<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 01/01/2015 09:31 PM, Richard Smith
wrote:<br>
</div>
<blockquote
cite="mid:CAOfiQqmRKKPC2+s9NJkTvsVT9=jauh4uCaQ4GC-Bkf5YE=dipA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">On Mon, Dec 29, 2014 at 5:45 PM,
Nelson, Clark <span dir="ltr"><<a moz-do-not-send="true"
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
moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<br>
I like this idea a lot. <br>
We could implement this and just have<br>
<tt>__cpp_unicode_literals == 200704</tt><br>
be synonymous with<br>
<tt><a><code>__cpp_unicode_characters</code></a></tt><tt> == 200704<br>
</tt>The column in the SD-6 document would just have both both
options listed. We could put in a note to that effect.<br>
It seems ironic that our feature testing system has issues bit I
guess it's to be expected. ;-)<tt><br>
<br>
</tt>Alternatively we could have:<tt><br>
</tt><br>
<tt><a><code>__cpp_unicode_characters</code></a></tt><tt> == 200704</tt>
means "unicode character literals u'a' and U'a'"<tt><tt><br>
</tt></tt><tt>__cpp_unicode_literals == 200710</tt> means unicode
string literals u"", U"", u8""<br>
Then go back to <tt><a><code>__cpp_unicode_characters</code></a></tt>
with<br>
<tt><a><code>__cpp_unicode_characters</code></a></tt><tt> == 201411</tt>
means "unicode character literals u'a' and U'a' and u8'a'"<tt><tt><br>
</tt></tt>This would separate character literals and string
literals (as we have already started) but we wouldn't have a feature
with two synonymous macros. And it's logically defensible too.<br>
<br>
We would not be adding a new macro in either case.<br>
<blockquote
cite="mid:CAOfiQqmRKKPC2+s9NJkTvsVT9=jauh4uCaQ4GC-Bkf5YE=dipA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Features mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Features@isocpp.open-std.org">Features@isocpp.open-std.org</a>
<a class="moz-txt-link-freetext" href="http://www.open-std.org/mailman/listinfo/features">http://www.open-std.org/mailman/listinfo/features</a>
</pre>
</blockquote>
<br>
</body>
</html>