2016-07-16 1:09 GMT+02:00 Jonathan Wakely <jwak...@redhat.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? - Daniel
