Proposed resolution:

This wording is relative to N4981.

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

   -2- The name views::as_rvalue denotes a range adaptor object ([range.adaptor.object]). Let E be an expression and let T be decltype((E)). The expression views::as_rvalue(E) is expression-equivalent to:

   1. (2.1) — views::all(E) if T models input_range and same_as<range_rvalue_reference_t<T>, range_reference_t<T>> is true.

   2. (2.2) — Otherwise, as_rvalue_view(E).

[ St. Louis 2024-06-29; Status changed: Voting → WP. ]

[ 2024-05-08; Reflector poll ]

Set status to Tentatively Ready after seven votes in favour during reflector poll.

views::as_rvalue(r) equivalent to views::all(r) when r's reference and rvalue reference are of the same type, which means that in this case we only need to check whether the type of r models viewable_range.

However, libstdc++'s implementation always requires as_rvalue_view{r} to be valid, which leads to divergence when r is not an input_range (demo):

#include <ranges>

struct I {
  int operator*();
  using difference_type = int;
  I& operator++();
  void operator++(int);
};

std::ranges::range auto r = std::ranges::subrange{I{}, std::unreachable_sentinel}
                          | std::views::as_rvalue; // // well-formed in libc++/MSVC-STL, ill-formed in libstdc++

Although this is precisely a bug in libstdc++ that does not conform to the current wording, it is reasonable to require r to be an input_range to be consistent with the constraints of as_rvalue_view.