a new way for dynamic dispatch function

[fililili]

These days, I found Swift support 2 ways to do dynamic dispatch. Here is the example:

protocol Speak {
    func speak()
}

struct Dog: Speak {
    func speak() {
        print("Woof!")
    }
}

struct Cat: Speak {
    func speak() {
        print("Meow!")
    }
}

let animals : [any Speak] = [Dog(), Cat()]
for animal in animals {
    animal.speak()
}

func speakGeneric<T: Speak>(_ animal: T) {
    animal.speak()
}

for animal in animals {
    speakGeneric(animal)
}

One way is original OOP (animal.speak() ), one way is generic function (speakGeneric(animal) ). Looks like these ways are same in this example. However, if we replace protocol Speak to protocol Comparable, we can find the difference, only below generic function way dynamic dispatch can work, the original OOP way dynamic dispatch cannot compile.

let comps : [any Comparable] = [1, 2.0, "hello"]

func selfCompare<T: Comparable>(_ a: T) -> Bool {
    return a < a
}

for c in comps {
    print(selfCompare(c))
}

That's because generic function has external type information. When use generic function, we know when a < a, we compare 2 same type objects, but with original OOP way dynamic dispatch, we don't have such knowledge.
So, generic function way dynamic dispatch is more powerful. Then, can we support that in C++?
Yes, c++ has template function already. What we have to do is make the template function can support dynamic dispatch. That means, we have to make the template function can be called by type-erased object. So, if the template function can support incomplete type, it can support type-erased object, too. Here is an example:

#include <bit>
#include <iostream>
#include <array>
#include <string>

class incomplete;

template <typename T>
struct dispatch_object {
    T* p_obj;
    bool(*comparable)(const T*, const T *);
};
using dyn_dispatch_object = dispatch_object<incomplete>;
template <typename T>
const dyn_dispatch_object erase(const dispatch_object<T> obj) {
    return std::bit_cast<const dyn_dispatch_object>(obj);
}

template <typename T>
constexpr bool selfCompare(dispatch_object<T> obj) {
    return obj.comparable(obj.p_obj, obj.p_obj);
}
auto selfCompareErase = selfCompare<incomplete>;


int main() {
    int x = 1;
    constexpr bool (*int_compare)(const int*, const int*) = [](const int* a, const int* b) {
        std::cout << *a << std::endl;
        std::cout << *b << std::endl;
        return *a < *b; 
    };
    dispatch_object<int> int_obj{&x, int_compare};

    selfCompare(int_obj);
    
    double y = 2.3;
    constexpr bool (*double_compare)(const double*, const double*) = [](const double* a, const double* b) {
        std::cout << *a << std::endl;
        std::cout << *b << std::endl;
        return *a < *b; 
    };
    dispatch_object<double> double_obj{&y, double_compare};
    selfCompare(double_obj);
    
    std::string z = "4.5";
    constexpr bool (*string_compare)(const std::string*, const std::string*) = [](const std::string* a, const std::string* b) {
        std::cout << *a << std::endl;
        std::cout << *b << std::endl;
        return *a < *b; 
    };
    dispatch_object<std::string> string_obj{&z, string_compare};
    selfCompare(string_obj);

    std::array objs{erase(int_obj), erase(double_obj), erase(string_obj)};
    for(const auto& obj : objs) {
        selfCompareErase(obj);
    }
}

The selfCompare is template function, it's full of type information to ensure type safe. So does the selfCompareErase function, it can ensure type safe, too, and it support type-erased object.
It can be even more powerful, we can even write code in this way:

#include <iostream>
#include <array>
#include <cstdint>

class incomplete;

template <typename T>
bool selfCompare2(const std::array<T, 2>* as, std::size_t T_size, bool(*comparable)(const T*, const T *)) {
    std::uintptr_t abegin = reinterpret_cast<std::uintptr_t>(as);
    const T* a0 = reinterpret_cast<const T*>(abegin);
    const T* a1 = reinterpret_cast<const T*>(abegin + T_size);

    return comparable(a0, a1);
}
auto selfCompare2Erase = selfCompare2<incomplete>;

int main() {
    std::array<double, 2> fs{0.4, 0.5};
    bool (*double_compare)(const double*, const double*) = [](const double* a, const double* b) {
        std::cout << *a << std::endl;
        std::cout << *b << std::endl;
        return *a < *b; 
    };

    std::cout << selfCompare2<double>(&fs, sizeof(double), double_compare) << std::endl;    
    std::cout << selfCompare2Erase(
        reinterpret_cast<const std::array<incomplete, 2>*>(&fs),
        sizeof(double),
        reinterpret_cast<bool (*)(const incomplete*, const incomplete*)>(double_compare)
    ) << std::endl;
}

Generic function dynamic dispatch should be the most powerful way dynamic dispatch, I think every template function can be used in this way (if we convert value to ptr or reference by hand).
(In Jave, it's comparble interface is not T->T->bool, but T1->T2->bool, which is hard to use.)
(In rust, it cannot support comparable as dyn trait, for it has object safety limitation.)
(For Swift, it cannot support the final example.)

[mingxwa]

Hi @fililili,

Thanks for the examples. A few clarifications and how Proxy handles these patterns:

1. About the "incomplete placeholder" trick: the code as written relies on undefined behavior (even if it's benign in practice). Forming or depending on properties of an incomplete class type in those contexts isn't guaranteed by the standard. If you just need a "hole", prefer using void rather than inventing an incomplete stand‑in type.

2. Your first selfCompare example can be modeled directly with proxy without any UB. You can expose the free function via PRO_DEF_FREE_AS_MEM_DISPATCH. Minimal version:

#include <proxy/proxy.h>
#include <iostream>

template <class T>
bool SelfCompare(const T& a) {
  std::cout << a << '\n';
  return a < a;
}

PRO_DEF_FREE_AS_MEM_DISPATCH(FreeSelfCompare, SelfCompare);

struct SelfComparable : pro::facade_builder
    ::add_convention<FreeSelfCompare, bool() const>
    ::build {};

int main() {
  int x = 1;
  pro::proxy<SelfComparable> p = &x;
  // As member-style dispatch:
  p->SelfCompare();
  // Or as free (if you used PRO_DEF_FREE_DISPATCH instead):
  // SelfCompare(*p);
}

If you prefer the free function call syntax, swap PRO_DEF_FREE_AS_MEM_DISPATCH for PRO_DEF_FREE_DISPATCH and invoke SelfCompare(*p). Both are well-formed.

3. Your second selfCompare2 (comparing two dynamic objects) is straightforward using a facade‑aware overload plus RTTI for a safe downcast. Proxy provides proxy_indirect_accessor plus the rtti skill for proxy_cast:

#include <proxy/proxy.h>
#include <iostream>

template <class F>
using SelfCompareOverload = bool(const pro::proxy_indirect_accessor<F>&) const;

template <class T, class F>
bool SelfCompare(const T& a, const pro::proxy_indirect_accessor<F>& b) {
  const T& tb = proxy_cast<const T&>(b);  // Throws if the underlying type of b is not T
  std::cout << a << '\n';
  std::cout << tb << '\n';
  return a < tb;
}

PRO_DEF_FREE_DISPATCH(FreeSelfCompare, SelfCompare);

struct SelfComparable : pro::facade_builder
    ::add_convention<FreeSelfCompare,
         pro::facade_aware_overload_t<SelfCompareOverload>>
    ::add_skill<pro::skills::rtti>   // Enables proxy_cast
    ::build {};

int main() {
  int x = 1, y = 2;
  pro::proxy<SelfComparable> p1 = &x;
  pro::proxy<SelfComparable> p2 = &y;
  SelfCompare(*p1, *p2);
}

Notes:

• facade_aware_overload_t routes the dynamic second argument through proxy_indirect_accessor so you can downcast when types match.
• proxy_cast requires the rtti skill (or an alternative casting skill if you supply one).
• No undefined behavior is needed; the library's dispatch + RTTI skill handles the type erasure boundaries.

If you need constraints (e.g., requires < and operator<<), you can layer them via concepts on the template or introduce a dedicated convention with SFINAE/concepts before registering the dispatch.

I hope this helps! Let me know if you have any other questions.

[fililili]

Hi, @mingxwa . Thanks for your reply.

1. the reason I use incomplete type is because I want to utilize template function to check type safe, I hope the template selfcompare function can works for all type, otherwise the selfcompareErase function should compile false. And void doesn't satisfied that, for example:

template <typename T>
struct foo;
template <>
struct foo<void> {};

template <typename T>
void fake(foo<T>){}
auto fakeErase = fake<void>;
// auto fakeInt = fake<int>; // cannot comiple

The fakeErase can compile but the fakeInt cannot, which is not expected. I hope all fake<T> can compile only if fakeErase can compile.
2.1. In my example, selfCompare is implemented by compare. In other word, selfCompare is composed by compare. However, we can not only compose compare to selfCompare, but also compose compare to other functions. For example:

#include <bit>
#include <iostream>
#include <array>
#include <string>

class incomplete;

template <typename T>
struct dispatch_object {
    T* p_obj;
    bool(*comparable)(const T*, const T *);
    void (*inc)(T*);
    T* (*clone)(const T*);
    void (*destroy)(T*);
};
using dyn_dispatch_object = dispatch_object<incomplete>;
template <typename T>
const dyn_dispatch_object erase(const dispatch_object<T> obj) {
    return std::bit_cast<const dyn_dispatch_object>(obj);
}

template <typename T>
constexpr bool selfCompare(dispatch_object<T> obj) {
    return obj.comparable(obj.p_obj, obj.p_obj);
}
auto selfCompareErase = selfCompare<incomplete>;

template <typename T>
constexpr bool selfCompareInc1(dispatch_object<T> obj) {
    T* new_p_obj = obj.clone(obj.p_obj);
    obj.inc(new_p_obj);
    bool ret = obj.comparable(obj.p_obj, new_p_obj);
    obj.destroy(new_p_obj);
    return ret;
}
auto selfCompareInc1Erase = selfCompareInc1<incomplete>;

template <typename T>
constexpr bool selfCompareInc2(dispatch_object<T> obj) {
    T* new_p_obj = obj.clone(obj.p_obj);
    obj.inc(new_p_obj);
    obj.inc(new_p_obj);
    bool ret = obj.comparable(obj.p_obj, new_p_obj);
    obj.destroy(new_p_obj);
    return ret;
}
auto selfCompareInc2Erase = selfCompareInc2<incomplete>;


int main() {
    int x = 1;
    constexpr bool (*int_compare)(const int*, const int*) = [](const int* a, const int* b) {
        std::cout << *a << std::endl;
        std::cout << *b << std::endl;
        return *a < *b; 
    };
    constexpr void (*int_inc)(int *) = [](int *a) {
        *a = *a + 1;
    };
    constexpr int* (*int_clone)(const int *) = [](const int *a) {
        return new int{*a};
    };
    constexpr void (*int_destroy)(int *) = [](int *a) {
        delete a;
    };
    dispatch_object<int> int_obj{&x, int_compare, int_inc, int_clone, int_destroy};

    selfCompare(int_obj);
    selfCompareInc1(int_obj);
    selfCompareInc2(int_obj);
    
}

And these selfCompareXXX are composed by compareble, and we can use all these selfCompareXXX for a just comparable object. But in your example, we have to implement selfCompareAbleXXX for each of them, it's hard to use.
2.2. In my selfCompare2, I don't compare two dynamic objects, we just compare sub objects of one dynamic objects. The dynamic object can be std::array<int>, then we always compare int and int; the dynamic object can be std::array<double>, then we always compare double and double. However, not matter what std::array<T> is, we always compare two same type objects, so we don't need rtti and should never throw type cast err.
What's more, we cannot only input array<T, 2>, but array<T, n> or std::vector<T> and sort them. Such usage cannot be done in other way.

[fililili]

In fact, the idea is from type system.
What we really create is an existential type. And existential type exist X, P(X) is equivalent to forall Y, (forall X, P(X) -> Y) -> Y.
So for forall Y, (forall X, P(X) -> Y) -> Y, if we pass it a generic function that has type forall X, P(X) -> Y, it gets result Y. Pass a generic function to existential type should be the most powerful usage for existential type.

[mingxwa]

Hi @fililili,

Thank you for the thoughtful follow up (and your patience). Your Church encoding analogy is exactly the model the library leans on: a proxy is an existential, a facade is the introduction / elimination interface.

You've raised two great points. Let me try to address them with refined examples (and fix an earlier misunderstanding on my side about your second scenario).

1. Composition of Operations

In my example, selfCompare is implemented by compare. ... we can not only compose compare to selfCompare, but also compose compare to other functions. ... But in your example, we have to implement selfCompareAbleXXX for each of them, it's hard to use.

You were right: only expose the primitive vocabulary once, every higher level combination stays as an ordinary template that happens to take a proxy.

Minimal example (primitives: < and ++ plus copyability):

#include <proxy/proxy.h>
#include <iostream>

// 1. Define the primitive operations in a facade
// This is our "P(X)" - the set of things we know about the erased type.
template <class F>
using CompareOverload = bool(const pro::proxy_indirect_accessor<F>&) const;

template <class T, class F>
bool operator<(const T& a, const pro::proxy_indirect_accessor<F>& b)
    requires(!std::is_same_v<T, pro::proxy_indirect_accessor<F>>) {
  return a < proxy_cast<const T&>(b);
}

struct Composable : pro::facade_builder
    ::add_convention<pro::operator_dispatch<"<">, pro::facade_aware_overload_t<CompareOverload>>
    ::add_convention<pro::operator_dispatch<"++">, void()>
    ::add_skill<pro::skills::rtti>
    ::support_copy<pro::constraint_level::nontrivial>
    ::build {};

// 2. Write generic algorithms that USE the primitives.
// These are the "forall X, P(X) -> Y" functions.
// They operate on any proxy that satisfies the `Composable` facade.

// Corresponds to your `selfCompareInc1`
bool selfCompareInc1(const pro::proxy<Composable>& p) {
  pro::proxy<Composable> clone = p;
  ++*clone;
  bool result = *p < *clone;
  return result;
}

// Corresponds to your `selfCompareInc2`
bool selfCompareInc2(const pro::proxy<Composable>& p) {
  pro::proxy<Composable> clone = p;
  ++*clone;
  ++*clone;
  bool result = *p < *clone;
  return result;
}

int main() {
  // Create a proxy for an `int`.
  pro::proxy<Composable> p = pro::make_proxy<Composable>(10);

  std::cout << std::boolalpha;
  std::cout << "p < p+1 ? " << selfCompareInc1(p) << std::endl; // true
  std::cout << "p < p+2 ? " << selfCompareInc2(p) << std::endl; // true
}

One facade, many free algorithms. proxy_cast appears only where a facade aware overload needs to recover T. Using it is encouraged: it performs a defined runtime relation check and then asks the underlying lifetime model (owning, borrowed, shared, custom skill) for a safe view of the object. That means you can freely compare or combine proxies that manage their storage differently without accidentally bypassing reference stability rules. The indirection cost is typically on par with any other dispatched call; only replace it with a custom unchecked cast skill when profiling proves it is a hot cost and you fully control object provenance.

2. Container Access via a Thin Element Facade

We can stay with the same element facade and add a very small container accessor facade that only returns element views. That directly expresses your second pattern without inventing a stride header or per element metadata structure.

Minimal pattern:

template <class T>
auto GetImpl(T&& container, std::size_t index) {
  return &container.at(index); // yields a pointer; proxy wraps it
}
PRO_DEF_FREE_AS_MEM_DISPATCH(MemGet, GetImpl, Get);

struct ComposableContainer : pro::facade_builder
    ::add_convention<MemGet, pro::proxy_view<Composable>(std::size_t)>
    ::build {};

bool selfCompare2(const pro::proxy<ComposableContainer>& pc) {
  auto a0 = pc->Get(0); // proxy_view<Composable>
  auto a1 = pc->Get(1);
  return *a0 < *a1;     // reuses the same `<` primitive from Section 1
}

That is all you need. If you later want size or iteration you can add those separately, but they are not required to demonstrate the idea, and keeping it small avoids distracting from the point.

A note: the previous proxy_view issue with facade aware overloads (see #347) is fixed on main and will ship in the next release. If you stay on 4.0 and hit it, a simple workaround is to use a plain pro::proxy<Composable> return (proxy can also represent a non owning state, just without encoding the lifetime model on the type) instead of proxy_view for that accessor.

In short: Proxy encodes an existential type (exists T. P(T)) by letting you name P once in a facade and then write ordinary generic algorithms that consume erased values through that facade. Happy to continue the discussion or look at another pattern you would like to model.

[fililili]

Hi, @mingxwa . Thanks for your reply.
The key idea is, the comparable should be T->T->bool, when people compare two objects, we always hope these two objects have same type. It doesn't make sense if we compare two different type.
However, according to the reason I mentioned above, sometimes the comparable become T1->T2->bool or T->comparable->bool, it's more complexed than T->T->bool and need extra type cast. (the type cast need extra time to check type safe and may failed)
In your example, you write:

  auto a0 = pc->Get(0); // proxy_view<Composable>
  auto a1 = pc->Get(1);
  return *a0 < *a1;

However, nobody can ensure that a0 and a1 are created by same type. In fact, for function GetImpl, we can return int if index is 0, return string if index is 1.

// note to remove the add_convention ++
template <class T>
pro::proxy_view<Composable> GetImpl_(T&&, std::size_t index) {
  if (index == 0) {
    static int a = 0;
    return &a;
  }
  else {
    static std::string a = "hello";
    return &a;
  }
}

Then a0 and a1 are different type, the code can compile but will throw type cast err. But with generic function + incomplete type, the comparable is T->T->bool, no type cast is needed, so such case never comes.

[mingxwa]

Hi @fililili,

Thanks for the thoughtful follow up (and for the patience while I caught up). I will keep this concise.

Core point about Comparable as T -> T -> bool

I agree the natural semantic for a Comparable relation is that both operands have the same concrete type. When you pass two independently erased objects, the abstraction must either

• prove they are the same erased type or
• perform a runtime check (e.g. proxy_cast) and potentially fail.

If you want to guarantee sameness without any runtime check, you need to shift the abstraction boundary so the pair of references (or iterators) is what gets erased, not each element separately. That is exactly the trade: moving type information outward removes the dynamic check but increases abstraction complexity.

Clarifying intent (performance vs stronger static guarantee)

I am not fully certain whether your primary goal is

• (a) eliminating the cost of an occasional proxy_cast, or
• (b) making it impossible for a heterogeneous source to compile in a context that assumes homogeneity.

If it is (b), then letting the abstraction operate over something like pair<T&, T&> (or a view of two positions) is the right direction. If it is (a), the measured overhead of the successful proxy_cast path is typically a single metadata compare + branch; removing it rarely shows up unless you are in a very tight loop that is otherwise fully optimized.

Pair (witness) pattern

Below is a minimal illustration using a witness whose payload is the tuple of two references. The key observation: the existential now ranges over a single concrete type T captured twice; no runtime cross-type comparison is needed. This answers the concern that two independently acquired element handles might differ.

template <class Pair> requires (std::tuple_size_v<Pair> == 2)
bool IsSortedImpl(const Pair& p) { return std::get<0>(p) < std::get<1>(p); }
PRO_DEF_FREE_AS_MEM_DISPATCH(MemIsSorted, IsSortedImpl, IsSorted);

struct ComparableWitness : pro::facade_builder
		::add_convention<MemIsSorted, bool() const>
		::build {};

template <class T>
auto GetComparableWitnessImpl(T&& container, std::size_t i, std::size_t j) {
	return pro::make_proxy<ComparableWitness>(std::tie(container.at(i), container.at(j)));
}
PRO_DEF_FREE_AS_MEM_DISPATCH(MemGetComparableWitness, GetComparableWitnessImpl, GetComparableWitness);

struct ComposableContainer : pro::facade_builder
		::add_convention<MemGetComparableWitness,
				 pro::proxy<ComparableWitness>(std::size_t i, std::size_t j) const>
		::build {};

bool selfCompare(const pro::proxy<ComposableContainer>& pc) {
	pro::proxy<ComparableWitness> w = pc->GetComparableWitness(0, 1);
	return w->IsSorted();
}

What this demonstrates:

• The homogeneous requirement is enforced structurally: you only ever expose a witness built from a pair of like-typed elements at the point both are still statically T.
• No per-call proxy_cast is needed in the IsSorted comparison itself.
• The cost is extra facade surface (another convention returning a secondary proxy) and slightly higher conceptual weight.

About returning mixed types intentionally

You noted that a container accessor could fabricate heterogeneity (index 0 returns int, index 1 returns std::string). That is true; any abstraction that returns two independently erased handles permits it. The design choice is: do we

• allow that and pay a runtime check in algorithms that assume sameness, or
• disallow it by construction via a pair witness facade as above.

Proxy supports both; you pick based on the guarantees you want consumers to rely on.

On the incomplete placeholder technique

Using an incomplete stand-in to drive template acceptance is a Church-encoding style trick. In this setting you can achieve the same expressive power more directly by

• spelling the primitive operation set once in a facade, then
• writing generic algorithms parameterized on a proxy<Facade>.

If an algorithm only type-checks when a specific primitive exists, that constraint expresses the same logical dependency without requiring the placeholder type. The difference is mostly stylistic; the proxy route keeps you within defined behavior and encodes the existential boundary explicitly.

I hope this clarifies the trade-offs. Feel free to follow up with any further questions.