I would definitely be in favor of something like this, in fact I have basically this in my own code at present to allow for highly generic code involving tuple-like objects. I'm not sure it should be under std::ranges however; maybe it could just have a different name? "get" isn't super descriptive after all.

Also, I'm not sure if it would perhaps be desirable to have any object usable with structured bindings also be passable to this CPO. It might make sense because things with get functions/methods defined are usable with structured bindings, but also not everything that's destructurable is intended to act like a tuple, so it might get weird.

I hadn't considered C-arrays to be tuple-ish before but I guess it might make sense if std::array is.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, October 25th, 2021 at 10:08 PM, Desmond Gold Bongcawel via Std-Proposals <std-proposals_at_[hidden]> wrote:

> get has been defined as a function template in std::ranges for std::ranges::subrange to obtain the pair of iterator and sentinel for structured binding support. (if necessary)
>
> My suggestion is that "get" for std::ranges::subrange should be defined in namespace std for the CPO purposes of std::ranges::get or may be defined as a member function template.
>
> std::ranges::get will be redefined its name as a customization point object.
>
> From the following definition, get is defined as a variable template where the non-type template parameter I denotes the index of the tuple-like object.
> inline namespace /* unspecified */ {
> template <size_t I>
> inline constexpr /* unspecified */ get = /* unspecified */;
> }
>
> A call to std::ranges::get
> 1. is expression-equivalent to "return get<I>(std::forward<Tup>(tup))"
> - where any declarations of get with appropriate template arguments can be found in ADL.
> 2. otherwise, is expression-equivalent to "return std::forward<Tup>(tup).template get<I>()"
> - where get is a member function template with appropriate template arguments.
> 3. otherwise, if the type is equal to an array type, then it is expression-equivalent to "return tup[i]"
>
> The potential benefits of std::ranges::get are to be encouraged used for functions that use std::get for tuple-like to support user-defined types such as std::apply in which internally used std::get where it prevents from passing a user-defined type that has no std::get overload.