Can anyone help to explain why we should wrap the operation implementation into a struct _op? about libunifex

[lewissbaker]

The reason we do this, generally, is to restrict the set of types/namespaces that are looked up when performing argument-dependent-lookup name-resolution - typically for finding tag_invoke() overloads.

Normally, when you make an ADL-call on a type it looks for an overload in the associated namespaces of the arguments to that call.
The associated namespaces include:

• the namespace in which the type was declared
• the associated namespaces of any of the base-classes
• the associated namespaces of any of the template arguments (if the type is a specialisiation of a class-template)

Generally we want to limit the set of overloads of tag_invoke the compiler needs to consider during overload resolution for compile-time reasons.

Declaring our types (operation-states, senders, receivers) as non-template classes nested within template classes means that those types are no longer specialisations of templates - but the types are still dependent on the template arguments. And so this means that the compiler doesn't consider the associated namespaces of the template arguments.

For example:

// The normal way
template<typename S, typename R>
class op { ... };

// The ADL-isolation way
template<typename S, typename R>
struct _op {
  class type { ... };
};
template<typename S, typename R>
using op = typename _op<S, R>::type;

If we write:

op<some_sender, some_receiver> o;
unifex::start(o);

then this dispatches to the ADL-call tag_invoke(tag_t<unifex::start>, o) and so will look for tag_invoke() in the associated namespaces of unifex::start CPO and of op<some_sender, some_receiver>.

If we use the straight-forward approach for templates then this will not only look for hidden-friends inside op but also for hidden-friends inside some_sender and some_receiver and all of their associated namespaces. As many senders/receivers used in generic algorithms are themselves templates which are templated on other senders/receivers, this can lead to quite a large number of associated types/namespaces that the compiler needs to search when looking for overloads of tag_invoke.

As these types are also likely to have declared tag_invoke overloads for other CPOs (e.g. set_value, connect, get_stop_token, etc.) this can lead to the compiler creating very large overload-sets to consider whenever it resolves a tag_invoke overload.

By using the ADL-isolation way, we are actually passing a non-template class as an argument that is still dependent on those same template arguments. But since it is a non-template class, the compiler no longer uses the rule that it needs to consider associated namespaces of template arguments and so we eliminate a large number of potential tag_invoke overloads and thus greatly improve compile times.

I hope that makes sense.

[npuichigo]

Thanks a lot for the detailed reply.