Forwarding reference

[Kim-J-Smith]

Maybe Forwarding reference is needed here

Fix

In file v4/proxy.h line 298

origin:

template <class P, class F, bool IsDirect, class D, qualifier_type Q, bool NE,
          class R, class... Args>
R invoke_dispatch(add_qualifier_t<proxy<F>, Q> self,
                  Args... args) noexcept(NE) {
  /* ... */
}

fix:

template <class P, class F, bool IsDirect, class D, qualifier_type Q, bool NE,
          class R, class... Args>
R invoke_dispatch(add_qualifier_t<proxy<F>, Q> self,
                  Args&&... args)  noexcept(NE) {  /// CHANGE HERE
  /* ... */
}

Also, v4/proxy.h line 330 should also change from Args... to Args&&...

origin:

struct overload_traits_impl : applicable_traits {
  using return_type = R;
  template <class F>
  using dispatcher_type = R (*)(add_qualifier_t<proxy<F>, Q>,
                                Args...) noexcept(NE);

  template <class P, class F, bool IsDirect, class D>
  static constexpr auto dispatcher =
      &invoke_dispatch<P, F, IsDirect, D, Q, NE, R, Args...>;

  template <class P, bool IsDirect, class D>
  static constexpr bool applicable_ptr =
      invocable_dispatch<P, IsDirect, D, Q, NE, R, Args...>;
};

fix:

struct overload_traits_impl : applicable_traits {
  using return_type = R;
  template <class F>
  using dispatcher_type = R (*)(add_qualifier_t<proxy<F>, Q>,
                                Args&&...) noexcept(NE); /// CHANGE HERE

  template <class P, class F, bool IsDirect, class D>
  static constexpr auto dispatcher =
      &invoke_dispatch<P, F, IsDirect, D, Q, NE, R, Args...>;

  template <class P, bool IsDirect, class D>
  static constexpr bool applicable_ptr =
      invocable_dispatch<P, IsDirect, D, Q, NE, R, Args...>;
};

Perf

Forwarding reference can avoid the need for a second copy of objects with high copy overhead, but it is not friendly to scalar objects and trivial objects. Consider using smart_forward_t instead. In v4/proxy.h line 897, the function pointer call here cannot be inlined, so the parameter passing value at this location needs to be optimized!

Args... double-copy

Args&&... Arguments must be passed via stack, even if they are scalar or trivial.

smart_forward_t<Args>... Best solution

  // Is trivial for the purposes of calls. (trivially destruct, copy and move)
  // See https://itanium-cxx-abi.github.io/cxx-abi/abi.html#non-trivial-parameters .
  template <typename T>
  struct is_call_trivial : public std::bool_constant<
    std::is_trivially_destructible<T>::value
      && std::is_trivially_copy_constructible<T>::value
      && std::is_trivially_move_constructible<T>::value
  > {};

  // Used to choose either perfect forwarding or pass-by-value.
  // Pass-by-value is faster for scalar types because they can
  // be passed by the register rather than the stack.
  template <typename T>
  using smart_forward_t = std::conditional_t<std::is_scalar<T>::value
    || (sizeof(T) <= sizeof(void*) && is_call_trivial<T>::value), 
    T, T&&>;

Also see https://reviews.llvm.org/D55045

// Used to choose between perfect forwarding or pass-by-value. Pass-by-value is
// faster for types that can be passed in registers.
template <typename _Tp>
using __fast_forward =
    typename _VSTD::conditional<_VSTD::is_scalar<_Tp>::value, _Tp, _Tp&&>::type;

[Kim-J-Smith]

diff --git a/include/proxy/v4/proxy.h b/include/proxy/v4/proxy.h
index dcebcd3..75de8d8 100644
--- a/include/proxy/v4/proxy.h
+++ b/include/proxy/v4/proxy.h
@@ -293,11 +293,28 @@ decltype(auto) get_operand(P&& ptr) {
     return *std::forward<P>(ptr);
   }
 }
+
+// Is trivial for the purposes of calls. (trivially destruct, copy and move)
+// See https://itanium-cxx-abi.github.io/cxx-abi/abi.html#non-trivial-parameters .
+template <typename T>
+struct is_call_trivial : public std::bool_constant<
+  std::is_trivially_destructible<T>::value
+  && std::is_trivially_copy_constructible<T>::value
+  && std::is_trivially_move_constructible<T>::value
+> {};
+
+// Used to choose either perfect forwarding or pass-by-value.
+// Pass-by-value is faster for scalar types because they can
+// be passed by the register rather than the stack.
+template <typename T>
+using smart_forward_t = std::conditional_t<std::is_scalar<T>::value
+  || (sizeof(T) <= sizeof(void*) && is_call_trivial<T>::value), T, T&&>;
+
 struct internal_dispatch {};
 template <class P, class F, bool IsDirect, class D, qualifier_type Q, bool NE,
           class R, class... Args>
 R invoke_dispatch(add_qualifier_t<proxy<F>, Q> self,
-                  Args... args) noexcept(NE) {
+                  smart_forward_t<Args>... args) noexcept(NE) {
   if constexpr (Q == qualifier_type::rv) {
     if constexpr (std::is_base_of_v<internal_dispatch, D> &&
                   is_bitwise_trivially_relocatable_v<P>) {
@@ -327,7 +344,7 @@ struct overload_traits_impl : applicable_traits {
   using return_type = R;
   template <class F>
   using dispatcher_type = R (*)(add_qualifier_t<proxy<F>, Q>,
-                                Args...) noexcept(NE);
+                                smart_forward_t<Args>...) noexcept(NE);
 
   template <class P, class F, bool IsDirect, class D>
   static constexpr auto dispatcher =

[mingxwa]

Hi Kim,

Thank you for the suggestion and for digging into the dispatch path so carefully.

The current behavior is intentional. In Proxy, the erased dispatcher signature is part of the library's ABI surface, not just an internal optimization detail. In particular, both the dispatcher type and the invoke path are designed to keep that ABI explicit and predictable, instead of baking in assumptions about a specific platform, ABI, or workload.

I also looked at the performance angle more closely, including the function-pointer hop you called out. Since that call cannot be inlined, the calling convention does matter here, so I ran a small benchmark comparing the current pass-by-value behavior with a pass-by-reference variant for types such as std::unique_ptr, std::shared_ptr, std::string, and std::vector:
bcbe0c7...faec2af . Here's some data from the generated report (the last 4 rows from the generated benchmarking-report.

	MSVC on Windows	GCC on Ubuntu	Clang on Ubuntu	Apple Clang on macOS	NVIDIA HPC on Ubuntu	Intel oneAPI on Ubuntu
Passing std::unique_ptr by value (existing proxy behavior) vs. by reference	🟡proxy is about 2.8% slower	🟡proxy has similar performance	🟢proxy is about 8.3% faster	🟡proxy is about 1.0% faster	🟡proxy has similar performance	🟢proxy is about 9.1% faster
Passing std::shared_ptr by value (existing proxy behavior) vs. by reference	🔴proxy is about 19.1% slower	🔴proxy is about 12.1% slower	🟡proxy is about 3.3% slower	🟡proxy is about 0.6% faster	🔴proxy is about 17.5% slower	🟡proxy is about 2.9% slower
Passing std::string by value (existing proxy behavior) vs. by reference	🔴proxy is about 24.0% slower	🟢proxy is about 9.9% faster	🟢proxy is about 22.4% faster	🟢proxy is about 16.2% faster	🔴proxy is about 11.2% slower	🟢proxy is about 22.4% faster
Passing std::vector by value (existing proxy behavior) vs. by reference	🔴proxy is about 23.5% slower	🟡proxy has similar performance	🟡proxy has similar performance	🟡proxy is about 0.1% faster	🟡proxy has similar performance	🟡proxy has similar performance

The result was mixed across toolchains. Passing by reference helped on some configurations, especially MSVC/Windows, but it also regressed others, notably Apple Clang in several cases. So at the library level, this does not look like a universally better default.

The smart_forward_t idea is interesting, and I agree with the general motivation behind it. The difficulty is that it would still move target- and ABI-specific policy into Proxy's erased dispatch layer. Proxy tries to stay neutral there. If a particular domain benefits from passing certain arguments by reference, users can already express that directly when authoring their conventions, which gives them control without forcing the same tradeoff on everyone else.

Because of that, I'm inclined to keep the current behavior as-is.

Mingxin

[Kim-J-Smith]

Thank you for the thorough explanation and benchmarks. I now fully understand the importance of ABI stability and why the dispatcher signature must stay explicit and predictable.

The mixed results across toolchains make it clear there's no universally better default. I also see how smart_forward_t would introduce implicit, platform‑dependent policy, which goes against Proxy's neutral design.

I respect your decision to keep the current behavior. Thanks again for your time and deep analysis.