[SG10] Updates to SD-6

Ed Smith-Rowland 3dw4rd at verizon.net
Fri Jan 9 16:19:54 CET 2015


On 01/08/2015 08:29 PM, Richard Smith wrote:
> On Thu, Jan 8, 2015 at 9:25 AM, Nelson, Clark <clark.nelson at intel.com 
> <mailto:clark.nelson at 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.
>
>     > > > 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 at isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/features

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/features/attachments/20150109/dcaf93cc/attachment.html 


More information about the Features mailing list