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: Daniel Krügler <daniel dot kruegler at gmail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 16 Jul 2016 14:55:16 +0200
- Subject: Re: [PATCH] Add constexpr to iterator adaptors, array and range access
- Authentication-results: sourceware.org; auth=none
- References: <20160715230956.GA18883@redhat.com>
2016-07-16 1:09 GMT+02:00 Jonathan Wakely <email@example.com>:
> 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 possible.
> 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 because
> 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?
As much as I hate the current restrictions, I tend to suggest to
follow them strictly in __STRICT_ANSI__ mode.
> Here's the patch, but I'm not committing it yet.
Since I made a similar (unintentional) omission recently myself:
Shouldn't you touch std::__debug::array as well? What about other
functions from std::__debug?