On Fri, Jan 9, 2015 at 7:19 AM, Ed Smith-Rowland <3dw4rd@verizon.net> wrote:
On 01/08/2015 08:29 PM, Richard Smith wrote:
On Thu, Jan 8, 2015 at 9:25 AM, Nelson, Clark <clark.nelson@intel.com> 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.
> > > 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
Features@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/features


_______________________________________________
Features mailing list
Features@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/features