Experimenting with Function Overloading in Rust: Why It Matters
Today, the Inside Rust blog published a technical write-up I submitted about a new nightly experiment called “splat”: an early, incomplete look at more ergonomic function and method overloading in Rust, aimed at making it easier to call overloaded foreign functions (starting with C++) from Rust code.
Before Rust’s end users or anyone in the wider open source community dives into the technical details, I wanted to give some context on where this experiment comes from, and why it matters
The Rust/C++ Interop Initiative
The Rust/C++ Interop Initiative, a Rust Foundation effort aimed at making Rust and C++ work together more smoothly, is the driving force behind the splat experiment.
The initiative is funded by Rust Foundation Platinum Member Google, which makes my work as a contractor for the Interop Initiative possible. As part of my role, I collaborate closely with the Rust Project and broader ecosystem stakeholders. My work includes making concrete progress on the Rust/C++ Interop Problem Space Mapping goal, facilitating discussions across language and tooling communities, and helping coordinate technical efforts like the splat experiment.
The technical post uses C++ as its example throughout, since it’s widely known and has significant existing interop tooling. But the experiment itself isn’t C++-specific; the Rust Foundation’s goal is to support a range of interop tooling and foreign function interface (FFI) languages over time.
Context for the wider community
Splat is deliberately scoped as a mapping exercise, not a feature proposal. Its purpose is to see how far Rust’s existing trait system can be pushed to enable foreign-language overload resolution, before committing to any particular design.
Overloading is used in different ways across C++ libraries, and overload resolution rules vary across different FFI languages. We want to explore how Rust’s existing rules can support this overloading, and what can be done outside the compiler to enable ergonomic overloading, across different API styles and languages.
What the experiment finds (where the type system bends easily, where it resists overloading, what diagnostics are needed) will directly inform whether and how any future #[overload]-style feature gets proposed through the normal RFC process.
Because there’s no RFC yet, this is a good moment for interested Project members to get involved informally (testing edge cases, reporting bugs, or weighing in on design tradeoffs in #t-lang/interop) while the design space is still wide open, rather than after key decisions have been locked in.
Context for Rust end-users
Nothing changes yet for Rust end-users, and that’s by design. This is a nightly-only, feature-gated experiment with no RFC. It’s not coming to stable Rust any time soon, and it may never ship in anything resembling its current form.
But it is a concrete signal of where the language is headed on C++ interop. Today, calling overloaded C++ functions from Rust means writing (or generating) manual boilerplate for every overload, using Rust traits, or creating uniquely named functions for each overload. Splat is a first step toward making that more ergonomic, and the long-term goal is a world where you can call overloaded FFI functions without thinking about tuples or traits at all.
If you work with mixed Rust/C++ codebases, this is worth watching. If you don’t, there’s nothing to do here yet; just consider this an early look at where things might be headed.
You can read my full technical write-up, including the experiment design, a runnable example, and current limitations, on the Rust Project blog: https://blog.rust-lang.org/inside-rust/2026/08/19/overloading-experiment/
Splat is just one piece of the broader Rust/C++ Interop Initiative. Expect another update on the initiative’s progress in the coming weeks!
