为什么每个循环的 c++ 接受右值但 std::ranges 不接受？

Question

A statement like this compiles without error:

for (int i : std::vector<int>({0, 1}))
  std::cout << i;

But a statement like this does not:

std::vector<int>({0, 1}) |
  std::views::filter([](int i) { return true; });

Why are r-values allowed in for each loops but not in std::range pipes? Is there a way I could get something like the second to work, without having to declare a variable?

Answer 1

The for-loop works fine because the vector<int> (rvalue) is valid while the loop is evaluated.

The second code snippet has 2 issues:

• The predicate must return a bool
• the vector<int> you are using in the views object is dangling by the time it is evaluated, so the compiler does not accept it.

If instead of a vector<int> rvalue, the object cannot dangle (lvalue) or holds references into something else that cannot not dangle, this would work.

For example:

auto vec = std::vector<int>({0, 1});
auto vw = vec | std::ranges::views::filter([](int i) { std::cout << i; return true; });

Or you can pass an rvalue that has references to a non-dangling vector<int> object, like std::span :

auto vec = std::vector<int>({0, 1});
auto vw = span{vec} | std::ranges::views::filter([](int i) { std::cout << i; return true; })

Here, std::span is still a rvalue, but the compiler accepts it because the author of std::span has created an exception for it.

For a custom type with references into something else (typically views), you can create your own exception by creating a specialization of the template variable enable_borrowed_range .

In the case of vector it would look like this (but don't do this! ):

template<> // don't do this
inline constexpr bool ranges::enable_borrowed_range<std::vector<int>> = true;

Your code now compiles but it will trigger undefined behavior because the vector is dangling once the view is evaluated.

Answer 2

This works with latest MSVC STL and libstdc++ ( demo ), thanks to P2415R2 .

Prior to P2415R2, filter_view always stores the underlying vector by reference (via a ref_view ). It was deemed unwise to store a copy of vector . Because a view is supposed to be cheap to copy, cheap to move, and cheap to destroy. Storing a copy of vector would have unexpected performance penalty.

And due to lifetime issues, it doesn't make sense to have a reference to rvalue vector .

But P2415R2 points out that a view can as well be non-copyable, while still be cheap to move and reasonably cheap to destroy.

So P2415R2 introduced owning_view , a non-copyable view that stores a copy of a range rvalue, and made standard range adaptors use that view.

The end result is, creating a filter_view from a vector rvalue works with standard library implementations that implement P2415R2.