Call an overloaded C++ function from Rust

[teor2345]

Currently, it is very difficult to call most overloaded C++ functions from Rust, because Rust doesn't have first-class overload resolution.

This use case is supported by another project goal:

• https://rust-lang.github.io/rust-project-goals/2026/overloading-for-ffi.html

That project goal contains a FAQ including prior art and current workarounds.

Example Code

What's currently possible:

• using exact types and requiring non-overlapping impls
• using existing unstable features
• using provider traits to allow incoherence

Depends On

• Tracking issue for Fn traits (unboxed_closures & fn_traits feature) rust-lang/rust#29625
• RFC: inherent trait implementation rust-lang/rfcs#2375
• Lossless Integer Round-Trips between Rust and C++ #6 (for integer overloads)
• Add missing impl Fn for &mut F where F: Fn rust-lang/rust#148271 (maybe?)

Related Work

• Tracking issue: Allow autoderef and autoref in operators (experiment) rust-lang/rust#44762
• Allow using Fn(A, B, C) -> _ for unconstrained FnOnce::Output. rust-lang/rust#47815
• Cannot call implementations of the Fn* traits on references rust-lang/rust#42736 (comment)
• Tracking issue for experiments around coercions, generics, and Copy type ergonomics rust-lang/rust#44619

Previous Work

• https://internals.rust-lang.org/t/pre-pre-rfc-splatting-for-named-arguments-and-function-overloading/24012
• https://docs.rs/overload/latest/overload/ (only for operators)
• https://docs.rs/overloadf/latest/overloadf/ (for functions)
• cxx and Zngur rename overloads with numeric suffixes, but this can cause function name conflicts

User Questions

• https://users.rust-lang.org/t/is-there-a-simple-way-to-overload-functions/30937
• https://internals.rust-lang.org/t/discussion-about-overloading-forked-from-pre-rfc-named-arguments/16990
• https://users.rust-lang.org/t/why-rust-doesnt-have-function-overloading/80416
• https://internals.rust-lang.org/t/justification-for-rust-not-supporting-function-overloading-directly/7012
• https://stackoverflow.com/questions/24594374/how-can-an-operator-be-overloaded-for-different-rhs-types-and-return-values (outdated?)

Sources

• C++ overload set resolution

[teor2345]

An example of the splat attribute:
https://hackmd.io/@rust-lang-team/ryrNyiFPbe#Function-overloading-for-FFI

The current experiment is:

• use the attribute at the definition site
• the compiler automatically rewrites the callers of those definitions from separate arguments into a tuple

https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/On.20overloading/near/578785469

trait MethodArgs : Tuple {
    fn call_method(self, this: &Foo);
}

impl Foo {
    fn method(&self, #[splat] args: impl MethodArgs) { args.call_method(self) }
}

impl MethodArgs for (i32, String) {
    fn call_method(self, this: &Foo) { dbg!(self.0) }
}

impl MethodArgs for (i32,) {
    fn call_method(self, this: &Foo) { dbg!(self.0) }
}

Foo.method(42);
Foo.method(42, "asdf".to_owned());
// becomes:
Foo::method(&Foo, (42,))
Foo::method(&Foo, (42, "asdf".to_owned()))

[iAmChidiebereh]

Hi @teor2345

I been reading more on this use case. The more I read, the more interesting this problem gets. I will love to add an example to the repo that handles overloading in terms of difference in arity, using one of the current workarounds.
This issue links to 3 different workarounds that are currently possible.. I will love to build up on workaround 2 using unstable features and key ideas like trait bounds and trait dispatch. Please let me know if I can go ahead with this. Thank you.

[iAmChidiebereh]

Also, using nightly features means the current CI checks will fail for the pr. Therefore, with your permission, I could work on the CI workflow to detect if an example PR uses nightly features and if true, runs cargo +nightly instead of regular cargo...
I will have to add a step to install nightly when needed too for this to work. I will have to update the readme in example folder to capture this too.

This change only affects PRs that uses nightly. Stable examples still use plain cargo as it is currently.

This will be a standalone PR since my proposed PR will depend on it.

If you approve this, I can go ahead with this now. I will be awaiting your response. Thank you

[teor2345]

For now, please wait before doing anything, because I'm just about to create some new tasks for people to do.

[iAmChidiebereh]

For now, please wait before doing anything, because I'm just about to create some new tasks for people to do.

Alright, I will... Thank you