I find it common to want to constrain a range to return a particular type. Something like
void f(std::ranges::range_of<unsigned> auto&& range_of_unsigned) { ... }
It would be trivial to define such a concept, or to forego the abbreviated template syntax and use a requires clause, but it seems to me this should be a vocabulary concept.
There's the question of whether the type should be same_as or convertible_to, perhaps there is room for two concepts here.
The problem with range_of is what exactly that should mean. Should range_of<unsigned> actually match any range of integral (i.e. convertible_to) or just specifically ranges of prvalue unsigned (i.e. same_as)? But same_as wouldn't even match vector<unsigned>, so if you want that did you actually want same_as but matching on value_type instead? Or decays_to?
So... sure, container-compatible-range is one of those things. But the problem with range_of<T> is what exactly you wanted to check your T against.
Which has not yet been made non-exposition-only, but I suspect it's only a matter of time before someone brings a paper to that effect.
Note that technically you cannot write your own "STL-style" container — one e.g. suitable as a
backing store for std::stack — without knowing about from_range_t and
container-compatible-range. But the STL still gets away with leaving it as exposition-only because it's literally a two-liner and (because of how Concepts subsumption works) there's no difference between using the actual STL's two-liner or writing the same two-liner in your own namespace.
–Arthur
What are you even talking about? from_range_t is part of the public interface of ranges::to, and no part of it actually uses container-compatible-range internally. Your constructor on from_range_t can be constrained however you want.
Barry