Best extension mechanism to be able to adopt third-party dependencies?

Question

I am currently trying to get my feet wet with concepts. Let us assume that I have a concept:

template <class T> concept Initable = requires (T&t) { { init(t) }; };
  // just for demonstration purposes, real concept makes more sense ...

and I want to provide an adoption layer for a third-party class like std::optional to implement this concept, what would be the most seemless way for me to do so?

Obviously, the following piece of code fails:

template <std::semiregular T>
T& init(std::optional<T> &v) { /* contents not that important */ v = T{}; return *v; }

static_assert(Initable<std::optional<int>>, "Oh no!"); // Fails!

The reason is two-phase lookup.

When trying to resolve init in the Initable concept during phase 1, my definition of init is not available, because it is provided below the Initable concept.

When trying to resolve it during phase 2, my definition is not found via argument-dependent lookup, because it is not provided in the std namespace.

Two obvious solutions, thus, would be to either provide the definition of init before defining the Initable concept or move init to the std namespace.

But I want to implement that concept for std::optional without

• relying on a particular definition/include order,
• populating the std namespace and
• using too much boiler-plate code at the caller site.

What would be the best way to do so? Could I make it somewhat easier to accomplish this when defining the Initable concept?

Basically I am asking, is this possible?

#include <concepts>
#include <optional>

template <class T>
concept Initable =
    requires (T& t) { init(t); } // May be changed to make the task easier.
;

// Insert code *here* that magically makes std::optional implement Initable.

static_assert(Initable<std::optional<int>>, "std::optional is not initable!");

And, if not, what would be the next best thing?

Answer 1

Resolving to any function that is visible during template instantiation is clearly against the principles of two-phase lookup. I decided to take a different approach instead and use a dummy parameter that is defined in a separate customization namespace:

namespace CP { // CP = CustomizationPoint
    struct Token {};
}

It is now possible, to define the init function in either the CP namespace or the namespace, the object is defined in:

namespace std {
    template <class T> void init(std::optional<T> &v, CP::Token) { ... }
    // illegal, but works -- do not declare stuff in namespace std.
}

namespace CP {
    template <class T> void init(std::optional<T> &v, CP::Token) { ... }
}

This is already pretty nice. It would be even nicer, if the definition in the std namespace would not require the CP::Token parameter. This can be done by providing a function object that will resolve to the correct function (similar to customization point objects that got introduced into the standard library):

constexpr inline struct {
    template <class T>
    auto operator()(std::optional<T>& v, CP::Token t) const
        -> decltype(init(v, t), []{}())
    {
        init(v, t);
    }

    template <class T>
    auto operator()(std::optional<T>& v, ...) const
        -> decltype(init(v), []{}())
    {
        init(v)
    }
} init;

This function object is a bit bulky, but it will resolve to the variant with the CP::Token parameter, if it is available and otherwise fall back to the variant without the token parameter, if that one is available.

To me, this seems to be a pretty sane approach that is perfectly extendable and even allows us to override an implementation that already has the right name, but the wrong semantics.

The concept must be modified slightly for this to work:

template <class T> concept Initable = requires (T&t) { init(t, CP::Token{}); };