Re: [PATCH] Add constexpr to iterator adaptors, array and range access

[Ville Voutilainen <ville dot voutilainen at gmail dot 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?

I think it's reasonable to make the functions constexpr even when the standard
doesn't allow it, and if c++17 allows them to be constexpr, make the functions
constexpr in other standard modes as well. We could of course ask whether
LWG thought about applying the changes to previous standards or not.

> 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).

That's certainly "safer".

> How strict do we want to be about obeying the "implementors can't add
> constexpr" rule in these cases?

I'd rather not be strict.