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 > 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?
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 compliant code. 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. Cheers, Oleg
