<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/08/2015 08:29 PM, Richard Smith
wrote:<br>
</div>
<blockquote
cite="mid:CAOfiQqnemxhoQRniXmjwv-uN811b9vUeBYS-K1L27hzv8b8jyg@mail.gmail.com"
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"><<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: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>
</div>
</div>
</blockquote>
I think we all agree that there'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>
<blockquote
cite="mid:CAOfiQqnemxhoQRniXmjwv-uN811b9vUeBYS-K1L27hzv8b8jyg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
<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>