<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">&lt;<a moz-do-not-send="true"
              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'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">&lt;<a
                moz-do-not-send="true"
                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'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's for
                strings.<br>
                &gt; 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=""> &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'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=""> &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'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>