[SG10] Updates to SD-6

Ed Smith-Rowland 3dw4rd at verizon.net
Mon Jan 12 17:38:54 CET 2015


On 01/09/2015 04:35 PM, Richard Smith wrote:
> On Fri, Jan 9, 2015 at 7:19 AM, Ed Smith-Rowland <3dw4rd at verizon.net 
> <mailto:3dw4rd at 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 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.
>
>
> 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.

It's not sane.  That's what happens when you have to maintain Fortran77 
in your day job :-\.
I agree that we should weed out macros that can't be sanely used.

The real (slight) reluctance: There is a tiny risk removing macros that 
have been shipped.  OTOH, if no one in their right mind would use them 
then they shouldn't be out in the wild and then I say go ahead.
It might be nice to have this solidified soonish so I can maybe back out 
before something freezes.

Ed

>>         > > > 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  <mailto:Features at isocpp.open-std.org>
>>     http://www.open-std.org/mailman/listinfo/features
>
>
>     _______________________________________________
>     Features mailing list
>     Features at isocpp.open-std.org <mailto: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/20150112/565a6249/attachment.html 


More information about the Features mailing list