Rust Language Team Opens Nightly Experiment Testing Function Overloading for C++ Interop
Rust's Language Team invited developers to test an experimental nightly feature that lets overloaded FFI functions be called without tuple workarounds.
Overview
The Rust Language Team published a call for experimentation on August 19, 2026, inviting compiler and interop tool developers to try a new nightly-only mechanism for calling overloaded functions, according to Inside Rust. The work is being carried out “in partnership with the Rust Foundation’s Rust-C++ Interop Initiative,” which has been “experimenting with function overloading for FFI bindings,” the post says, and the project is now “at a stage where compiler and interop tool developers can start exploring function overloading.”
What We Know
According to Inside Rust, Rust nightly builds “from 2026-07-31 onwards have experimental support for more ergonomic function and method overloading,” implemented through what the post calls “the #[rustc_splat] attribute,” which lets “overloaded functions be called with separate arguments.”
Stable Rust already permits a limited form of overloading through traits and tuple arguments, but the calling syntax is awkward: overloaded arguments currently have to be passed as a single tuple, producing calls like hypot((2.0, 3.0, 6.0)). The new experimental attribute is meant to let the same call be written as hypot(2.0, 3.0, 6.0) instead — Inside Rust notes there is “no double parentheses required.”
The Rust Foundation frames the motivation around C++ interoperability, writing that 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.” The stated long-term aim is to “call overloaded FFI functions without thinking about tuples or traits at all.” The Foundation describes the broader effort as “a mapping exercise, not a feature proposal,” intended to “see how far Rust’s existing trait system can be pushed to enable foreign-language overload resolution.”
Funding for the work comes from Google. The Rust Foundation post states that “the initiative is funded by Rust Foundation Platinum Member Google, which makes my work as a contractor for the Interop Initiative possible.” The post is authored by Teor, who holds that contractor role; the Inside Rust announcement is credited to “teor, on behalf of the Language Team.”
Inside Rust also credits a specific contributor working on ergonomics: “Ajay Singh, a Rust Project Outreachy intern, is working on a macro to make splat-based overloading more ergonomic.” The post lists design goals for the experiment as keeping the effort focused on how to “keep Rust nice” while aiming to “make calling overloaded FFI functions easy.” Looking further ahead, it raises the possibility that “in the shiny future, Rust might have an #[overload] attribute that ‘just works’ to call overloaded foreign functions with the same name.”
Developers who encounter problems are directed to a specific feedback channel: Inside Rust asks that anyone who thinks they “found a bug or limitation” raise it “in the #t-lang/interop channel on Zulip.”
What We Don’t Know
Both posts are explicit that this remains an early-stage, unstable experiment. Inside Rust states that “like most Rust language experiments, this nightly feature has no RFC, and can change or be removed at any time.” The Rust Foundation post is similarly hedged, saying “it’s not coming to stable Rust any time soon, and it may never ship in anything resembling its current form.” Neither post gives a timeline for a formal RFC or stabilization decision. The Foundation post describes the overloading work as “just one piece of the broader Rust/C++ Interop Initiative” and says to “expect another update on the initiative’s progress in the coming weeks,” without detailing what that update will cover.