<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"><<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>></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>
> > > N4051 Allow typename in a template template parameter<br>
> > > __cpp_typename_in_template_template_parm 201411<br>
> > > This may be too little to mess with.<br>
<br>
> > This is a really good question. The only way I could see this being used<br>
> > would be like so:<br>
> > #if __cpp_typename_in_template_template_parm<br>
> > #define TTP typename<br>
> > #else<br>
> > #define TTP class<br>
> > #endif<br>
<br>
> > with template template parameters declared like so:<br>
> > template<template<...> TTP X> ...<br>
<br>
> > Obviously, the interesting questions are, what sort of spelling might<br>
> > actually be used for the name of what I have called "TTP", and would anyone<br>
> > actually bother to write code like this?<br>
<br>
> It really depends what we think feature test macros are for. Another<br>
> possible use is this:<br>
<br>
> #if !__cpp_typename_in_template_template_parm<br>
> #error You need a compiler supporting C++17 to build this code.<br>
> #endif<br>
<br>
> So, do we only care about feature-test macros that allow a program to use<br>
> the feature if present and reasonably fall back if not, or do we also care<br>
> about cases where the only reasonable response to a missing feature is to<br>
> cause an error (or fail a configure check or similar)? The latter case<br>
> covers this feature, trigraph removal, digit separators, and probably some<br>
> 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's not enough justification to create the<br>
macro. Here'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's possible that we have already invented some macros that I wouldn't<br>
really consider to be adequately justified. Nobody's perfect. :-(<br>
That's part of the reason we don'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'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="">
> > > N4268 - Allow constant evaluation for all non-type template arguments<br>
> > > __cpp_const_eval_of_non_type_template_args<br>
><br>
> > I have tweaked the spelling of this slightly:<br>
> > __cpp_const_eval_all_nontype_template_args<br>
<br>
<br>
> That seems quite verbose. How about:<br>
<br>
> __cpp_nontype_template_arg_eval<br>
<br>
> Even then, I worry that the "eval" is missing the point. The change removes<br>
> a syntactic restriction as much as it introduces different semantics. I<br>
> wonder if simply<br>
<br>
> __cpp_nontype_template_args == 201411<br>
<br>
> would be acceptable; I think that'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>