This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Add constexpr to iterator adaptors, array and range access
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Jonathan Wakely <jwakely at redhat dot com>, libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Sat, 16 Jul 2016 10:39:28 +0900
- Subject: Re: [PATCH] Add constexpr to iterator adaptors, array and range access
- Authentication-results: sourceware.org; auth=none
- References: <20160715230956.GA18883@redhat.com>
On Sat, 2016-07-16 at 00:09 +0100, Jonathan Wakely wrote:
> This patch implements http://wg21.link/p0031 which adds constexpr to
> most operations on std::reverse_iterator, std::move_iterator,
> std::array, as well as std::advance, std::distance, and the
> range-access functions std::begin, std::rbegin etc.
> Strictly speaking, those functions should only be constexpr in C++17
> and not before, but this patch makes them constexpr whenever
> That means the changes are fully implemented for C++14 (and the
> feature-test macro is defined) but only partially implemented for
> C++11, because some of the functions can't be constexpr in C++11.
> My thinking is that if the committee has decided that these functions
> *should* be constexpr, and changed them for C++17, then it doesn't
> serve users to make them non-constexpr in C++11 and C++14 just
> the standard says so.
> How do other people feel about that?
The alternative would be to define a new _GLIBCXX17_CONSTEXPR macro
> and use it in all these places, so they're only constexpr in C++17
> (and probably for -std=gnu++14 too, but not -std=c++14).
> How strict do we want to be about obeying the "implementors can't add
> constexpr" rule in these cases?
Other std libs are even more ignorant regarding this and do stuff like
defining several C++11 features and functionalities even if C++11 is
not enabled, which can be annoying at times.
One thing that could happen with those extra constexpr, is having
people accidentally writing non-C++11/14-compliant code on a newer
C++17 toolchain, although they actually wanted to write C++11/14
GCC itself, with its conservative toolchain requirements, is probably a
good example. If GCC's compiler requirement is bumped from C++98/03 to
C++11 some day, most GCC developers are probably going to use a pretty
recent GCC version for GCC development. As a consequence, silent non
-compliant constexpr related constructs might slip in over and over
again simply because people don't notice. So everyone would need to
keep some older C++11-only toolchain version just for testing the
build. I can imagine this to be a source of frustration. If users
want to write C++11 or C++14 code, the toolchain should assist them in
doing so as much as possible.
I'd vote for the _GLIBCXX17_CONSTEXPR macro.