<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 class="HOEnZb"><div class="h5"><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><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
&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 class="HOEnZb"><font color="#888888"><br>
Clark<br>
</font></span></blockquote></div><br></div></div>