> > > 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.

> > > 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