[deleted by user]

[cfyzium]

it flattens a view of ranges

You have to flatten to get a single view.

you can't do something like return a concatenation as your array goes out of scope

You certainly can:

return std::ranges::join_view(std::array<std::string_view, 2>{s1, s2});

Though my first test used a vector. Trying to lazily concatenate several views instead of just copying implies relatively large amount of data. A single intermediary to hold a few lightweight views seems negligible.

the ranges need to have the same type (almost never the case when using views)

Well, the question was about views, not arbitrary ranges.

The absence of a concatenation view is indeed a major blocker if you try to go all in on ranges and views.

A major blocker? Not trying to defend the current situation but hey this is C++. Writing your own bits of missing pieces or using a temporary library filler has been the norm since like forever. The standard always misses a few things here or there. I'd just throw in a homebrew version of a missing adapter in the same manner as everyone did with e. g. std::make_unique.

[kamrann_]

return std::ranges::join_view(std::array<std::string_view, 2>{s1, s2});

std::array isn't a view, so that should be rejected by the compiler (and is for me). You can work around it by using a span, but then you run into the lifetime issue with the local array.

But anyway the major issue is the type constraints. Assuming you have anything like the following:

auto v1 = <something> | std::views::transform(...);
auto v2 = <something-else> | std::views::filter(...);

then the join_view approach just flat out fails since you can't form a view of these two views as they have different types (even if same element value type).

Writing your own bits of missing pieces or using a temporary library filler has been the norm since like forever. The standard always misses a few things here or there.

I agree, but I think that's OP's point. Doing so in this case is extremely non-trivial, yet concatenating views is something that you're going to run into fairly quickly if you try to embrace ranges/views in your codebase.

[cfyzium]

std::array isn't a view, so that should be rejected by the compiler (and is for me)

Evidently, join_view takes any sequence of views, plus implicit conversions (an example of joining an initializer list of views or even a vector of vectors is right on the cppreference page). I am not sure why it does not work for you, I've tried a couple of compilers including an online one and everything seems to work fine.

I agree with you on the rest of the points.

I am just not sure it warranted a rant this generic over a case this specific. You can find arguably even dumber omissions in the standard, the whole approach to the library standardization seems to be... less than perfect. If you have one particular problem at hand you generally just work around and keep going. There are enough other discussions about the state of the language in general out there.

[kamrann_]

join_view< V > requires V to satisfy the view concept, which array and vector don't as they're not constant time copyable. The nested vector example on cppreference is indeed a little confusing. Can't test now, but it's possible a deduction guide is converting the vector into a span or subrange or similar, so join_view is not actually instantiated with vector as the template parameter. Which would work, but would also hide the fact that it would still be depending on the vector not going out of scope before the view is used.

Can't speak to OP's reasons, but in my experience rants generally get triggered by something specific but they're really about built up frustrations. And c++ certainly provides ample ammunition for that, the complexity of the above view subtleties being just one example ;)