This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
Section: 25.7 [iterator.range] Status: New Submitter: Jiang An Opened: 2021-03-21 Last modified: 2021-04-20
Priority: 3
View other active issues in [iterator.range].
View all other issues in [iterator.range].
View all issues with New status.
Discussion:
Overloads for std::rbegin/rend for built-in arrays and std::initializer_list's has no preconditions and never throw exceptions, thus should be noexcept. LWG 2280 addressed a similar issue for std::begin/end.
Suggestion: change these declarations in 25.7 [iterator.range] (p10, 11, 12, 13) as indicated:template<class T, size_t N> constexpr reverse_iterator<T*> rbegin(T (&array)[N]) noexcept; template<class T, size_t N> constexpr reverse_iterator<T*> rend(T (&array)[N]) noexcept; template<class E> constexpr reverse_iterator<const E*> rbegin(initializer_list<E> il) noexcept; template<class E> constexpr reverse_iterator<const E*> rend(initializer_list<E> il) noexcept;
If this change is accepted, we may also specify conditional noexcept for std::crbegin/crend (in 25.7 [iterator.range] p14, 15), by adding noexcept(noexcept(std::rbegin/crend(c))), like in LWG 2280.
Conditional noexcept for other functions in 25.7 [iterator.range] (p2, 3, 7, 8, 16, 18, 20 22) may also be added for consistency.[2021-03-21; Daniel comments]
There is intentionally no P/R provided at this point, but I'm volunteering to provide it if we got feedback whether adding conditional noexcept specifiers similar to those provided by LWG 2280 would be preferred or not.
[2021-04-20; Reflector poll]
Priority set to 3.
Jonathan: This would create a strange situation where std::rbegin and std::crbegin on an initializer_list are noexcept but std::begin and std::cbegin aren't guaranteed to be (because an initializer_list uses the generic std::begin and std::cbegin overloads, which have no conditional noexcept).
Casey: I don't think we should mark these rbegin/rend overloads noexcept without making the pertinent reverse_iterator constructors conditionally noexcept.
Proposed resolution: