<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 01/09/2015 04:35 PM, Richard Smith
wrote:<br>
</div>
<blockquote
cite="mid:CAOfiQq=4x8AFk6Aps1OiYBY01W5NRNe35bTiL82Us=8t68LWcA@mail.gmail.com"
type="cite">
<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"><<a moz-do-not-send="true"
href="mailto:3dw4rd@verizon.net" target="_blank">3dw4rd@verizon.net</a>></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"><<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>
<div><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>
</div>
</div>
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>
</div>
</blockquote>
<div><br>
</div>
<div>That does not sound entirely sane to me: I think you'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>
</div>
</div>
</div>
</blockquote>
<br>
It's not sane. That's what happens when you have to maintain
Fortran77 in your day job :-\.<br>
I agree that we should weed out macros that can't be sanely used.<br>
<br>
The real (slight) reluctance: There is a tiny risk removing macros
that have been shipped. OTOH, if no one in their right mind would
use them then they shouldn't be out in the wild and then I say go
ahead.<br>
It might be nice to have this solidified soonish so I can maybe back
out before something freezes.<br>
<br>
Ed<br>
<br>
<blockquote
cite="mid:CAOfiQq=4x8AFk6Aps1OiYBY01W5NRNe35bTiL82Us=8t68LWcA@mail.gmail.com"
type="cite">
<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">
<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> >
> > 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><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 moz-do-not-send="true" href="mailto:Features@isocpp.open-std.org" target="_blank">Features@isocpp.open-std.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:Features@isocpp.open-std.org">Features@isocpp.open-std.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>