P2547R0 briefly summarised all the existing customisation point techniques and proposed language features to support writing customisation points. It is definitely the right direction and indeed simplifies the process of authoring customisation points as well as making it more compiler friendly. However, I’d like to add a little bit more.

noexcept Propagation and Expression Validation

One of the biggest hassles of authoring CPOs is to do the noexcept propagation and constraint (or SFINAE). We effectively need to write the function body three times

template <class... Ts>
auto operator()(Ts&&... ts) const
  noexcept(noexcept(expression-here))
  -> decltype(expression-here) {
    return expression-here;
}

The paper removes the need to declare a generic CP object with operator(), which removes lots of code of doing noexcept propagation and expression validation. This is great. But it turns out that this problem is not only for CPOs, it is a problem for all generic algorithms that does some forwarding. For example, the following code snippet is from the paper:

// Forward query-like calls onto inner receiver
template<auto cpo>
requires (!completion_signal<CPO>) && 
    std::invocable<decltype(cpo), const Receiver&> 
friend decltype(auto) cpo(const allocator_receiver& r)
    noexcept(std::is_nothrow_invocable<CPO, const Receiver&>) override { 
  return cpo(r.receiver);
}

And I can imagine this will still occur in other places

template <class Base>
class my_view::iterator{
    iterator_t<Base> base_;
public:
  iterator() requires std::default_initializable<iterator_t<Base>> 
            = default;

  //...
  friend void iter_swap(iterator const& x, iterator const& y)
    noexcept(std::is_nothrow_invocable<ranges::iter_swap, 
                                       const iterator_t<Base>&,
                                       const iterator_t<Base>&>)
    requires(std::indirectly_swappable<iterator_t<Base>, iterator_t<Base>>)
    override {
        ranges::iter_swap(x.base_, y.base_);
   }
};

That is still a lot of code just to do some forwarding. Yes this is not the problem of CPO but it would be nice to make it look slightly better.

It would be really nice to have syntax like this

template<auto cpo>
friend decltype(auto) cpo(const allocator_receiver& r)
    noexcept(auto) requires(auto) override { 
  return cpo(r.receiver);
}

What Happens If I Forget the override keyword

In traditional OOP, when we forget the override keyword (which happens all over the places and it is one of the most causes of my yellow squiggles in my IDE which I can’t fix as I don’t own the type), the implementation will still be selected and used.

It is not clear to me what would happen if the override keyword is accidentally forgotten. From what I understand from the paper, the function on longer participate the “customisation overload set”, and it will just become normal free function in the namespace scope or a hidden friend. And there is a chance that the user silently calls the default implementation. But if we make the compiler error in this case, we effectively reserves the name globally and defeats the purpose of the paper.

‘boost::hana’ Way of Doing CP

Most articles about CP does not mention the way boost::hana does it, although some of them briefly mentioned the plain old class template specialisation technique. boost::hana was created in the old times (C++11/C++14), but the idea remains valid and it does NOT rely on ADL at all. Its idea is quite simple, adding a user friendly layer to the plain old class template specialisation technique. However, it is not perfect has its own issues (that is why we need the language support!), but it is still good to mention it when we compare CP techniques.

CPO Declaration

namespace lib{

inline constexpr struct begin_fn{
    template <class T>
    struct impl{
        static void apply(...) = delete; 
        // can put default impl here if there is one
    };

    template<typename T>
    constexpr decltype(auto) operator()(T&& t) const {
        return impl<std::decay_t<T>>::apply((T&&) t);
    }
} begin{};

} // namespace lib

Algorithms can use lib::begin as a function or an object just like niebloids or tag_invoke CPOs. I intentionally skipped noexcept propagation and SFINAE (or requires constraint). It adds too much noise.

User Customisation

namespace client{

struct MyRange{
    int* first;
    int* second;
};

} // namespace lib

template<>
struct lib::begin_fn::impl<client::MyRange>{
    static constexpr auto apply(const client::MyRange& r){
        return r.first;
    }
};

How Does It Compare with Other CP ?

Let’s see what if it satisfies some of the points in the paper

• The ability to see clearly, in code, what the interface is that can (or needs to) be customised.
  • I think this is true for all the CP techniques. You need to declare the CP first and it is very obvious.
• The ability to provide default implementations that can be overridden, not just non-defaulted functions.
  • Yes. The default implementation is inside the primary template
• The ability to opt in explicitly to the interface.
  • Yes. Template specialisation is explicit
• The inability to incorrectly opt in to the interface (for instance, if the interface has a function that takes an int, you cannot opt in by accidentally taking an unsigned int).
  • Yes. Not sure if I understand it correctly but you have specialise for a particular type or a partial specialisation
• The ability to easily invoke the customised implementation. Alternatively, the inability to accidentally invoke the base implementation.
  • Yes. It is easy to call the cpo and very hard to call base implementations.
• The ability to easily verify that a type implements an interface.
  • I think this is false for all cases. If the customisation happens to be in a different file which does the customisation for a bunch of types in a generic way, it is impossible to find it out by just looking at the type.
• The ability to present an atomic group of functionality that needs to be customised together (and diagnosed early).
  • No
• The ability to opt in types that you do not own to an interface non-intrusively.
  • Yes.
• Allows customisation-point names to be namespace-scoped rather than names being reserved globally.
  • Yes. No ADL involved at all.
• Allows generic forwarding of Customization Point Objects through wrapper-types, including generic type-erasing wrappers (like std::optional) and adapters that customise some operations and pass through others.
  • No. But we can tweak it to make it possible. (e.g.) Making all the default impl inheriting from a template which does the forwarding if it exists.
• Concise syntax for defining CPOs and adding customisations for particular types.
  • No. Declaring CPO is the same as niebloid and tag_invoke and customisation requires class template specialisation which is verbose
• Support for copy-elision of arguments passed by-value to customisation points.
  • No.
• Far better compile times compared to the tag_invoke mechanism (avoids 3 layers of template instantiations and cuts down on SFINAE required to separate implementation functions)
  • It doesn’t have massive overload problem but it does require template instantiation.
• Far better error messages compared to the tag_invoke mechanism (tag_invoke does not distinguish between different customization point functions and results in sometimes hundreds of overloads)
  • Yes compared to tag_invoke. There are no hundreds of overloads. And the error message points to the = delete line when a type is missing a CP.

Summary

It is a great paper and we definitely need it. It would be good to answer my puzzles too.