<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 9, 2015 at 7:19 AM, Ed Smith-Rowland <span dir="ltr">&lt;<a href="mailto:3dw4rd@verizon.net" target="_blank">3dw4rd@verizon.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
    <div>On 01/08/2015 08:29 PM, Richard Smith
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Thu, Jan 8, 2015 at 9:25 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 class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div>
                <div><br>
                  &gt; &gt; &gt; N4051 Allow typename in a template
                  template parameter<br>
                  &gt; &gt; &gt;     
                   __cpp_typename_in_template_template_parm       
                  201411<br>
                  &gt; &gt; &gt; This may be too little to mess with.<br>
                  <br>
                  &gt; &gt; This is a really good question. The only way
                  I could see this being used<br>
                  &gt; &gt; would be like so:<br>
                  &gt; &gt; #if __cpp_typename_in_template_template_parm<br>
                  &gt; &gt; #define TTP typename<br>
                  &gt; &gt; #else<br>
                  &gt; &gt; #define TTP class<br>
                  &gt; &gt; #endif<br>
                  <br>
                  &gt; &gt; with template template parameters declared
                  like so:<br>
                  &gt; &gt; template&lt;template&lt;...&gt; TTP X&gt;
                  ...<br>
                  <br>
                  &gt; &gt; Obviously, the interesting questions are,
                  what sort of spelling might<br>
                  &gt; &gt; actually be used for the name of what I have
                  called &quot;TTP&quot;, and would anyone<br>
                  &gt; &gt; actually bother to write code like this?<br>
                  <br>
                  &gt; It really depends what we think feature test
                  macros are for. Another<br>
                  &gt; possible use is this:<br>
                  <br>
                  &gt; #if !__cpp_typename_in_template_template_parm<br>
                  &gt; #error You need a compiler supporting C++17 to
                  build this code.<br>
                  &gt; #endif<br>
                  <br>
                  &gt; So, do we only care about feature-test macros
                  that allow a program to use<br>
                  &gt; the feature if present and reasonably fall back
                  if not, or do we also care<br>
                  &gt; about cases where the only reasonable response to
                  a missing feature is to<br>
                  &gt; cause an error (or fail a configure check or
                  similar)? The latter case<br>
                  &gt; covers this feature, trigraph removal, digit
                  separators, and probably some<br>
                  &gt; others, which should presumably be treated
                  uniformly.<br>
                  <br>
                </div>
              </div>
              For my money, if the only plausible use of a feature-test
              macro would be to<br>
              control a #error directive, that&#39;s not enough
              justification to create the<br>
              macro. Here&#39;s how SD-6 already says it:<br>
              <br>
              (The absence of a tested feature may result in a program
              with decreased<br>
              functionality, or the relevant functionality may be
              provided in a different<br>
              way. A program that strictly depends on support for a
              feature can just try<br>
              to use the feature unconditionally; presumably, on an
              implementation lacking<br>
              necessary support, translation will fail.)<br>
              <br>
              It&#39;s possible that we have already invented some macros
              that I wouldn&#39;t<br>
              really consider to be adequately justified. Nobody&#39;s
              perfect. :-(<br>
              That&#39;s part of the reason we don&#39;t try to put our
              recommendations in the<br>
              standard itself.</blockquote>
            <div><br>
            </div>
            <div>OK, I think this is an entirely reasonable position. On
              that basis, I think we do not want a macro for N4051. (I
              think we also don&#39;t want a __cpp_digit_separators macro;
              how do we feel about removing it from our
              recommendations?)</div>
          </div>
        </div>
      </div>
    </blockquote></div></div>
    I think we all agree that there&#39;s no sane use for a macro for
    template template typename.<br>
    On the other hand I can maybe see surrounding blocks of constants
    with the digit separator macro.<br>
    Then dropping the unseparated block as the last platform implements
    digit seps.<br></div></blockquote><div><br></div><div>That does not sound entirely sane to me: I think you&#39;re suggesting that a programmer would duplicate some set of numeric literals, just so they could put digit separators in one copy of them. The risk of the two copies becoming out-of-sync seems like sufficient justification for any reasonable programmer to avoid that. Also, consider that #if-guarded code still needs to successfully tokenize, and literals with odd numbers of digit separators do not tokenize in C++11 and before.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite"><span class="">
      <div dir="ltr">
        <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>
                &gt; &gt; &gt; N4268 - Allow constant evaluation for all
                non-type template arguments<br>
                &gt; &gt; &gt;
                __cpp_const_eval_of_non_type_template_args<br>
                &gt;<br>
                &gt; &gt; I have tweaked the spelling of this slightly:<br>
                &gt; &gt; __cpp_const_eval_all_nontype_template_args<br>
                <br>
                <br>
                &gt; That seems quite verbose. How about:<br>
                <br>
                &gt;   __cpp_nontype_template_arg_eval<br>
                <br>
                &gt; Even then, I worry that the &quot;eval&quot; is missing the
                point. The change removes<br>
                &gt; a syntactic restriction as much as it introduces
                different semantics. I<br>
                &gt; wonder if simply<br>
                <br>
                &gt;   __cpp_nontype_template_args == 201411<br>
                <br>
                &gt; would be acceptable; I think that&#39;s my preferred
                spelling for this.<br>
                <br>
              </span>OK, thanks.<br>
              <span><font color="#888888"><br>
                  Clark<br>
                </font></span></blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </span><span class=""><pre>_______________________________________________
Features mailing list
<a href="mailto:Features@isocpp.open-std.org" target="_blank">Features@isocpp.open-std.org</a>
<a href="http://www.open-std.org/mailman/listinfo/features" target="_blank">http://www.open-std.org/mailman/listinfo/features</a>
</pre>
    </span></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
Features mailing list<br>
<a href="mailto:Features@isocpp.open-std.org">Features@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/features" target="_blank">http://www.open-std.org/mailman/listinfo/features</a><br>
<br></blockquote></div><br></div></div>