On Thu, Jan 8, 2015 at 9:25 AM, Nelson, Clark <[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?) > > > 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] http://www.open-std.org/mailman/listinfo/features
