Is it a disadvantage to have "names" coupled due to custom point objects?

Question

As we know, the CPO can use concepts to check the performance requirements(like input type, output type, etc.) of the user-defined function reload that it found. But they can't check the semantics of the user's function, right? Like the following codes show:

namespace My_A{
    struct A{};
    void some_name(A);//not fit
}

namespace My_B{
    struct B{};
    int some_name(B);//fit, but do unrelated matters
}

template<typename T>
concept usable_some_name =
requires(T arg) {
    some_name(arg) -> int;
};

struct __use_fn{
    template<typename T>
    int operator()(T a)
    {
        if constexpr (usable_some_name<T>)
            return some_name(a);
        // ...
    }
};

__use_fn use{};

It can weed out unqualified functions, but there is no guarantee that a "qualified" function will do what it is expected to do. If I want to make sure my code is error-free, either I have to circumvent the names' use of all the possible touched CPO used (which is impossible), or I have to make sure that my function of the same name (if any) has the semantics that those CPO expects (which also seems like an unreasonable burden) when all the CPO may be used.

Is that an unreasonable request that I must define my function to behave the same way as the ranges algorithm wanted every time they have just the same name that the ranges algorithm uses?

Compared to the traditional method:

template <>
struct hash<my_type>
{
    // ...
}

or

priority_queue<my_type, vector<my_type>, my_type_greater> pq;

We can easily find that in those traditional ways we can make our customization be called only when we clearly want, without any risk of miscall as CPO made.

Is the current CPO bringing something that is an over-coupling? (I know what it is designed for and what its advantages are, though) Is there any better way (maybe tag_invoke or what, I don't know) to resolve this problem?

Answer 1

Customization points have a number of built-in mechanisms that reduce the chance of an accidental match substantially.

Let us consider ranges::begin(t). This works on a type T which is either:

• An array
• Has a member begin
• Has an ADL-visible begin non-member function accessible via begin(t)

In the latter two cases, the selected begin function must

• Take no parameters other than t.
• Return an object which matches input/output iterator.

Therefore, in order for there to be a collision against ranges::begin, some other CPO must do all of the following:

• The CPO must choose the incredibly non-descript word "begin" for the name of the extensible function it is looking for.
• This function must take zero other parameters.
• This function must return a value for which a type matching input/output iterator could be a legitimate return type.

The last two in particular are kind of... rare. I mean even for "begin", what is really the likelihood that someone would use begin as a nullary extension function and its return value would legitimately be an iterator without actually being the first element of a range? That sounds vanishingly unlikely.

Now yes, the standard library CPOs do have the advantage of being... standard. Everybody knows that begin/end are for iterator ranges. So nobody would actually use them for CPOs.

But nobody's forcing you to use one-word names for these extension functions. The standard library does it, but you can use my_functionality_extension_method_name if it makes you feel safer about conflicts. Your CPO can still be named my_namespace::method_name. Indeed, you can have the member version be method_name while the non-member version is longer. Or whatever works for you.

Speaking of which, you need to keep in mind is the distinction between having a CPO and what the CPO does. A CPO exists to keep people from specifically overloading or specializing the function (and from using ADL to invoke it). That's why it is a function object instead of a regular function.

But nothing about being a CPO dictates how you extend them. ranges::data isn't based on whether you have an accessible data function. It instead works through std::to_address, which goes through pointer traits or a user-provided specialization.

So if you would rather use some other method for users to extend a CPO, like a traits class or whatever, you are free to do so. The CPO is just a mechanism for invoking that functionality.