C++ Logo

SG10

Advanced search

Subject: Re: [SG10] Updates to SD-6
From: Richard Smith (richard_at_[hidden])
Date: 2015-01-08 19:29:12


On Thu, Jan 8, 2015 at 9:25 AM, Nelson, Clark <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?)

> > > 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
>



SG10 list run by herb.sutter at gmail.com