On 01/09/2015 04:35 PM, Richard Smith wrote:
On Fri, Jan 9, 2015 at 7:19 AM, Ed Smith-Rowland <[email protected]
<mailto:[email protected]>> wrote:
On 01/08/2015 08:29 PM, Richard Smith wrote:
On Thu, Jan 8, 2015 at 9:25 AM, Nelson, Clark
<[email protected] <mailto:[email protected]>> wrote:
> > > N4051 Allow typename in a template template parameter
> > > __cpp_typename_in_template_template_parm 201411
> > > This may be too little to mess with.
> > This is a really good question. The only way I could see
this being used
> > would be like so:
> > #if __cpp_typename_in_template_template_parm
> > #define TTP typename
> > #else
> > #define TTP class
> > #endif
> > with template template parameters declared like so:
> > template<template<...> TTP X> ...
> > Obviously, the interesting questions are, what sort of
spelling might
> > actually be used for the name of what I have called
"TTP", and would anyone
> > actually bother to write code like this?
> It really depends what we think feature test macros are
for. Another
> possible use is this:
> #if !__cpp_typename_in_template_template_parm
> #error You need a compiler supporting C++17 to build this code.
> #endif
> So, do we only care about feature-test macros that allow a
program to use
> the feature if present and reasonably fall back if not, or
do we also care
> about cases where the only reasonable response to a missing
feature is to
> cause an error (or fail a configure check or similar)? The
latter case
> covers this feature, trigraph removal, digit separators,
and probably some
> others, which should presumably be treated uniformly.
For my money, if the only plausible use of a feature-test
macro would be to
control a #error directive, that's not enough justification
to create the
macro. Here's how SD-6 already says it:
(The absence of a tested feature may result in a program with
decreased
functionality, or the relevant functionality may be provided
in a different
way. A program that strictly depends on support for a feature
can just try
to use the feature unconditionally; presumably, on an
implementation lacking
necessary support, translation will fail.)
It's possible that we have already invented some macros that
I wouldn't
really consider to be adequately justified. Nobody's perfect. :-(
That's part of the reason we don't try to put our
recommendations in the
standard itself.
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?)
I think we all agree that there's no sane use for a macro for
template template typename.
On the other hand I can maybe see surrounding blocks of constants
with the digit separator macro.
Then dropping the unseparated block as the last platform
implements digit seps.
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.
It's not sane. That's what happens when you have to maintain Fortran77
in your day job :-\.
I agree that we should weed out macros that can't be sanely used.
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.
It might be nice to have this solidified soonish so I can maybe back out
before something freezes.
Ed
> > > N4268 - Allow constant evaluation for all non-type
template arguments
> > > __cpp_const_eval_of_non_type_template_args
>
> > I have tweaked the spelling of this slightly:
> > __cpp_const_eval_all_nontype_template_args
> That seems quite verbose. How about:
> __cpp_nontype_template_arg_eval
> Even then, I worry that the "eval" is missing the point.
The change removes
> a syntactic restriction as much as it introduces different
semantics. I
> wonder if simply
> __cpp_nontype_template_args == 201411
> would be acceptable; I think that's my preferred spelling
for this.
OK, thanks.
Clark
_______________________________________________
Features mailing list
[email protected] <mailto:[email protected]>
http://www.open-std.org/mailman/listinfo/features
_______________________________________________
Features mailing list
[email protected] <mailto:[email protected]>
http://www.open-std.org/mailman/listinfo/features
_______________________________________________
Features mailing list
[email protected]
http://www.open-std.org/mailman/listinfo/features
