Proposed resolution:

This wording is relative to N4981.

1. Modify [range.reverse.overview] as indicated:

   -1- reverse_view takes a bidirectional view and produces another view that iterates the same elements in reverse order.

   -2- The name views::reverse denotes a range adaptor object ([range.adaptor.object]). Given a subexpression E, the expression views::reverse(E) is expression-equivalent to:

   1. (2.1) — If the type of E is a (possibly cv-qualified) specialization of reverse_view, equivalent to E.base().

   2. (2.?) — Otherwise, if the type of E is a (possibly cv-qualified) specialization of empty_view ([range.empty.view]), single_view ([range.single.view]), or repeat_view ([range.repeat.view]), equivalent to decay-copy(E).

   3. (2.2) — Otherwise, if the type of E is cv subrange<reverse_iterator<I>, reverse_iterator<I>, K> for some iterator type I and value K of type subrange_kind,

      1. (2.2.1) — if K is subrange_kind::sized, equivalent to:

         subrange<I, I, K>(E.end().base(), E.begin().base(), E.size())

      2. (2.2.2) — otherwise, equivalent to:

         subrange<I, I, K>(E.end().base(), E.begin().base())

      However, in either case E is evaluated only once.

   4. (2.3) — Otherwise, equivalent to reverse_view{E}.

[ 2024-06-24; Reflector poll ]

Set priority to 3 after reflector poll. Send to LEWG for review. The `repeat` part is related to LWG 4019.

Currently, when views::reverse is applied to empty_view, single_view, or repeat_view, a reverse_view with the iterator type reverse_iterator will be produced.

Such an amount of instantiation seems less necessary for these three simple view types, since returning a copy of them is sufficient.

Note that this also makes views::repeat(0) | views::reverse | views::take(5) no longer timeout, which seems to be an improvement.