On Fri, Jan 9, 2015 at 7:19 AM, Ed Smith-Rowland <[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]> > 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 > [email protected]http://www.open-std.org/mailman/listinfo/features > > > > _______________________________________________ > Features mailing list > [email protected] > http://www.open-std.org/mailman/listinfo/features > >
_______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
