Provide access to `self` in weak dispatch?

[Shuenhoy]

The current example of weak dispatch is just a "not implemented". However, to make a more useful default implementation, it is very common to access self, so that we can implement a weak dispatch with other non-weak dispatches.

I have found this is possible by manually defining the dispatch as

struct dispatch_name : existing_dispatch {
  using existing_dispatch::operator();
  template <class Self, class... Args>
  decltype(auto) operator()(Self&& self, Args&&... args)
      noexcept(noexcept(default_func_name(std::forward<Self>(self), std::forward<Args>(args)...)))
      requires(requires { default_func_name(std::forward<Self>(self), std::forward<Args>(args)...); } and not std::same_as<Self, std::nullptr_t>) {
    return default_func_name(std::forward<Self>(self), std::forward<Args>(args)...);
  }
};

But it might be worth adding a new helper macro for this, what do you think about it?

[mingxwa]

@Shuenhoy It is an interesting idea to extend an existing dispatch to accept more types, but maybe macro PRO_DEF_FREE_DISPATCH is what you need.

When a type itself does not have a specific member function, you can define a free function template (probably in custom namespace) and turn it into a dispatch type via PRO_DEF_FREE_DISPATCH without needing an "intermediate" dispatch type.

It is by design that the fallback implementation of a "weak dispatch" should not be aware of the pointer itself. In this case, nullptr will be passed to the dispatch that may potentially optimize code generation. Please refer to named requirements ProDispatch for more details.

BTW, if you find PRO_DEF_FREE_DISPATCH is not as handy as PRO_DEF_MEM_DISPATCH because IDE may provide less hints when writing code, I have recently implemented a new macro PRO_DEF_FREE_AS_MEM_DISPATCH (see #189) that can turn a free function into a member function of proxy. This feature is now available on the main branch but the documentation is still in review. If things going well, this new macro will also be included in the upcoming 3.1 release.

Thank you for your interest in refining our work. Please let me know if you have any other questions or ideas.

[Shuenhoy]

Thanks for the reply!

It seems that the free dispatch feature has similar functionality that I proposed. But if I understand correctly, it may be less unified experiences when implementing a facade.

Here is my scenario that may make my ideas more clear:

To begin with, I have an EnergyWithGradient facade

export template <
    typename Scalar, typename Var, typename Gradient>
struct EnergyWithGradient
    : pro::facade_builder                                                                  //
      ::add_convention<spec::MemValue, Scalar(Var)>                                        //
      ::template add_convention<spec::MemGradient, void(Var, Gradient, Scalar)>            //
      ::build {};

I then realized that some time we need to compute the value and the gradient at the same time, and there is a chance to archive better performances than individually call .value and .gradient. But of course, not every EnergyWithGradient instance can benefit from that, so there should be a default implementation that just calls .value and .gradient.

So I manually define this weak dispatch

struct MemWeakValueGradient : MemValueGradient {
    using MemValueGradient::operator();
    template <class Self, class... Args>
    decltype(auto) operator()(Self &&self, Args &&...args) noexcept(
        noexcept(value_gradient(std::forward<Self>(self), std::forward<Args>(args)...)))
        requires(
            requires {
                value_gradient(
                    std::forward<Self>(self),
                    std::forward<Args>(args)...);
            } and not std::same_as<Self, std::nullptr_t> and
            not requires { std::forward<Self>(self).value_gradient(
                               std::forward<Args>(args)...); })
    {
        return value_gradient_default(std::forward<Self>(self), std::forward<Args>(args)...);
    }
};

So far, the experiences should be almost the same as the free dispatch. But when the users want to provide a customized implementation, they add a member method value_gradient to their type, just like the two other dispatch value and gradient, instead of a free function when using free dispatch. So the experiences are somehow more unified and similar to the C# 8 interface default method feature.

Further, I concern that using free dispatch for this purpose may unnecessarly increase the coupling between the implementation and the abstraction. One important advantage of proxy I see is that it is non intrusive, unlike the traditional virtual class you have to explicitly inherit the interface class. This is true for the member method, because a member method is not related to the abstraction in any sense explicitly. However, for the free dispatch, it seems to have explicitly provide an overload of a function in some specific namespace (decided by the dispatch definition, i.e. the abstraction), thus being related explicitly.

[mingxwa]

@Shuenhoy Thank you for the clarification. Looks like the implementation of value_gradient_default() in your code effectively invokes value_gradient(std::forward<Self>(self), std::forward<Args>(args)...). Is that correct?

What about defining a free function template that calls .value_gradient() when applicable, and fallback to .value() and .gradient() when an implementation type chooses not to provide a .value_gradient()? Like std::size(), it returns .size() for regular container types, and returns array size for C-style array types. For example,

namespace details {

template <class Self, class... Args>
decltype (auto) value_gradient(Self&& self, Args&&... args) {
  if constexpr (requires { std::forward<Self>(self).value_gradient(std::forward<Args>(args)...); }) {
    return std::forward<Self>(self).value_gradient(std::forward<Args>(args)...);
  } else {
    // compute with .value() and .gradient()
  }
}

}  // namespace details

PRO_DEF_FREE_DISPATCH(FreeValueGradient, details::value_gradient, value_gradient);

Note that the namespace of the free function is not bound to the namespace of the dispatch type. You can also turn it into a member function if you want, e.g., PRO_DEF_FREE_AS_MEM_DISPATCH(FreeValueGradient, details::value_gradient, value_gradient) (it won't compile with proxy 3.0, but will be available in the upcoming 3.1 release).

By definition, a "weak dispatch" is not equivalent to the "C# 8 interface default method feature". Specifically,

• Their motivations are different. The "weak dispatch" in proxy is designed to facilitate code generation (compilation speed and binary size), while a "default method" in C#, AFAIK, only serves as a syntactic sugar and won't improve code generation.
• Functionally, in a default method of a C# interface, it can access this and invoke other abstract methods (indirect calls) within the current interface. This is intentionally not supported by proxy to avoid generating redundant indirect calls.

[Shuenhoy]

Thanks for the answser!

The value_gradient_default() is just the branch // compute with .value() and .gradient() in your code. The requires in the previous comment should be corrected from value_gradient to value_gradient_default.

            requires {
                value_gradient_default( // <-- 
                    std::forward<Self>(self),
                    std::forward<Args>(args)...);
            } and not std::same_as<Self, std::nullptr_t> and

This wrapper function combined with the upcomming 3.1 feature should resolve my scenario. After looking close at them, I found my code in the previous comment seems to be almost an equivalent implementation as the free as mem dispatch you posted (the only difference is my code uses require clauses on the template, while yours uses an if constexpr ) and is not related to weak dispatch at all.

Probably these information should be added to the document, as weak dispatch (as well as its purpose) is a less well-known concept and seems to be easily confused with the more common default implementation feature supported in C# interface, Rust trait, Haskell typeclass, etc.

[mingxwa]

@Shuenhoy I agree that the motivation of PRO_DEF_WEAK_DISPATCH is not sufficiently documented today and may cause confusions for people who are familiar default methods in C# or Java. I will try to improve the spec. Thank you for the feedback!

[mingxwa]

@Shuenhoy I have filed #204 to improve the wording. Does it look good to you?