C++ Logo


Advanced search

Re: [SG10] Generalized/relaxed const. expr.

From: Thomas Plum <tplum_at_[hidden]>
Date: Tue, 4 Jun 2013 02:46:07 +0000
Maybe just "__cpp_constexpr11" and "__cpp_constexpr14"?

From: features-bounces_at_[hidden] [mailto:features-bounces_at_[hidden]] On Behalf Of Richard Smith
Sent: Monday, June 03, 2013 2:20 PM
To: Nelson, Clark
Cc: features_at_[hidden] (features_at_[hidden])
Subject: Re: [SG10] Generalized/relaxed const. expr.

On Mon, Jun 3, 2013 at 4:52 PM, Nelson, Clark <clark.nelson_at_[hidden]<mailto:clark.nelson_at_[hidden]>> wrote:
I wanted to get feedback from authors of proposals on macro names to represent their features as soon as possible; I started by turning Tom's list of C++11 features into a table in the same style as what we already have for C++14. (As background, please remember that, to the greatest degree that makes sense, I'm tending to use words from the title of the proposal paper to name the feature-test macro.)

The title of N2235, by which "constexpr" was introduced into C++, was basically "Generalized Constant Expressions". So the more or less mindless name of the macro might be "__cpp_generalized_constant".

Whereas N3652, which eliminates the constraints on a constexpr function, is entitled, in part, "Relaxing constraints on constexpr functions"; hence "__cpp_relaxed_constexpr".

It hardly seems likely that we will want to use the word "generalized" as part of two different macro names regarding constexpr -- but we could conceivably decide that this is a case for changing the value of a macro, instead of defining a new one.

>From my perspective as an implementer, the change that was voted into C++14 doesn't seem minor or subtle, but I guess opinions might differ.


I don't think either *generalized* or *relaxed* is sufficiently future-proof. What happens if C++17 generalizes constants further or relaxes more constexpr restrictions? And do we really want people to need to remember which features were "generalized" and which were "relaxed"? More generally, I don't think we should use names which describe a difference between C++ version N and C++ version N+1; instead, we should pick names which describe the features objectively (names which still make sense as features of C++ version aleph_0).

So, some strawman proposals:

1) For N2235, use __cpp_constexpr (emphasizing the new keyword)
For N3652, use __cpp_constexpr_statements (emphasizing that this is an extension of __cpp_constexpr, and that the primary change is that it permits almost any statements in constexpr functions)
2) N2235 has #define __cpp_constexpr 1, and N3652 has #define __cpp_constexpr 2.
3) N2235 has #define __cpp_constexpr 201103L and N3652 has #define __cpp_constexpr 2014xxL.

Received on 2013-06-04 04:53:15