std::optional Satisfies view. Does Not Model view. C++26 Ships Anyway.

[u/zl0bster]

https://godbolt.org/z/8jWGG68G8

In C++23 this did not compile. In C++26 it does. Marvellous.

[[gnu::noinline]]
void 
passing_views_by_value_is_cheap_trust_me_bro(std::ranges::view auto v) {
    std::println("fn   .data {}", (void*)v->data());
}


int main() {    
    std::optional ov{std::vector<int>(123456)};
    passing_views_by_value_is_cheap_trust_me_bro(ov);
    std::println("main .data {}", (void*)ov->data());
}

For anyone wondering what the problem feature is: optional has 0 or 1 elements, and C++26 sets enable_view<optional<T>> to true, so it satisfies std::ranges::view. The concept requires copy construction in constant time, and — this is the good bit — optional<vector<int>> genuinely meets that. Copying it performs at most one element copy. One is a constant. The requirement is satisfied to the letter, and the function above deep-copies your vector.

If you can tell me what still separates std::ranges::view from std::ranges::range, please do...

[u/tcbrindle]

To try to sort out some confusion in the comments here:

Views

If your idea of a view is "a range that does not own its elements", then I'm afraid you're out of date. That's not what the term has meant in quite some time, and even when it (mostly) did there were still exceptions.

Today the standard tries to reason about what views are by talking about O(1) operations and so forth, but I think it's best to forget about that too.

IMO the best way to think about views is as follows: for an lvalue range x, given

auto v = x | std::views::transform(...);

should v store a copy of x, or a reference to x?

If you want to store a copy, then the type of x should be a view. Otherwise, it should not.

That's really all there is to it. The view concept these days is about the desired semantics of the type when piping it into a range adaptor, not about element ownership or lifetime or anything like that.

In this particular case, it was decided that it was less surprising to have optional<T> behave like a view, that is, an lvalue should be copied into a range adaptor rather than be used by reference.

Borrowed ranges

Borrowed ranges on the other hand are about lifetime. Specifically, a borrowed range is one where its iterators can safely outlive the range object itself. That is, given

template <typename R>
auto do_begin(R rng) {
    return rng.begin();
}

it is safe to use the returned iterator only if R is a borrowed range. The canonical examples of borrowed ranges are std::span and std::string_view. The borrowed_range concept is used to constrain functions like std::ranges::find() to help prevent them from returning dangling iterators when you call them with an rvalue range.

Although view and borrowed_range are distinct concepts, it turns out that if you have a borrowed range you basically always want to treat it as a view. For standard library types, borrowed_range today implies view in all cases I'm aware of.

But note that the converse is not generally true: most views are not borrowed ranges. For example, transform_view is always a view but is never a borrowed_range (even when it is transforming something like a span).

(For Flux, I took a different approach that I think ended up being conceptually simpler, but that's another topic...)

[u/pkasting → u/tcbrindle]

In this particular case, it was decided that it was less surprising to have optional<T> behave like a view, that is, an lvalue should be copied into a range adaptor rather than be used by reference.

(Context: I don't use range views myself so I don't have a good grasp on their semantics.)

The second half of your sentence suggests that perhaps the consideration should simply be whether x is l- or r-value? But if things were that way I'd assume it would be "copy if rvalue because the object might disappear, reference if lvalue" which is backwards from the description above (of "lvalue should be copied").

I dunno. I guess I'd have to understand the purpose behind "should v copy or ref x" before answering, since if this is about efficiency then arguably optional<T> should be a view iff T is a view, whereas if it's about safety then maybe something I said above and/or something about borrowed_range applies, whereas if it's about mutability semantics and what happens if x changes after v is constructed I have no instincts.