On 01/09/2015 04:35 PM, Richard Smith wrote:
> On Fri, Jan 9, 2015 at 7:19 AM, Ed Smith-Rowland <3dw4rd_at_[hidden]
> <mailto:3dw4rd_at_[hidden]>> 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_[hidden] <mailto:clark.nelson_at_[hidden]>> 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_[hidden] <mailto:Features_at_[hidden]>
>> http://www.open-std.org/mailman/listinfo/features
>
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden] <mailto:Features_at_[hidden]>
> http://www.open-std.org/mailman/listinfo/features
>
>