Title
views::as_rvalue should reject non-input ranges
Status
ready
Section
[range.as.rvalue.overview]
Submitter
Hewill Kang

Created on 2024-04-27.00:00:00 last changed 1 month ago

Messages

Date: 2024-05-08.10:36:29

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

Date: 2024-05-15.00:00:00

[ 2024-05-08; Reflector poll ]

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

Date: 2024-04-27.00:00:00

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.

History
Date User Action Args
2024-05-08 10:36:29adminsetmessages: + msg14126
2024-05-08 10:36:29adminsetstatus: new -> ready
2024-04-28 08:20:12adminsetmessages: + msg14087
2024-04-27 00:00:00admincreate