Rust Tests a `splat` Bridge to C++—Before Function Overloading Gets an RFC

Rust is testing a small but consequential change at the language boundary: a nightly experiment called splat that could make overloaded C++ functions easier to call from Rust.

The experiment was described by the Rust Language Team on August 19, 2026. It is being developed with the Rust Foundation’s Rust-C++ Interop Initiative and is aimed first at foreign-function interfaces, rather than at redesigning ordinary Rust APIs.

Today, Rust can model a form of overloading through traits and tuples. That approach is type-safe, but it produces awkward calls. A generated binding may require hypot((2.0, 3.0, 6.0)) instead of the C++-style hypot(2.0, 3.0, 6.0). Another common workaround is to rename each foreign overload, producing functions such as func1 and func2.

Those workarounds create a maintenance problem. When a C++ library adds or removes an overload, its native callers generally continue to use the same overload set. Rust bindings, however, may need regenerated names, additional boilerplate, or manual compatibility work. The accepted Rust Project Goal therefore frames the problem as more than call-site aesthetics: supporting Rust callers should not impose a higher maintenance burden on C++ library owners.

The current experiment uses the internal #[rustc_splat] attribute. A function can accept a tuple of arguments while allowing callers to write the arguments separately. In the project’s example, implementations for two- and three-argument versions of C++ std::hypot are selected through the existing trait system, while the call sites look like hypot(3.0, 4.0) and hypot(2.0, 3.0, 6.0).

That design is deliberately provisional. The project is testing how far Rust’s existing type and trait machinery can support foreign overload sets, what diagnostics users need, and where Rust’s coherence rules resist patterns that C++ permits. C++ can contain overlapping candidates and resolve them through a multi-step “best viable function” process; Rust’s trait system generally rejects overlapping implementations instead of choosing between them.

The project goal also makes the strategic boundary clear. Rust does not need to reproduce C++ argument-dependent lookup or every C++ resolution rule. A future design may require explicit conversions or markers to disambiguate calls. The target is a predictable Rust interface to foreign APIs, not a wholesale import of C++ semantics.

For compiler and interop-tool developers, experimentation is already possible on Rust nightly builds from July 31, 2026 onward. The language post also notes recent work on rustdoc and function-pointer support, plus a standard-library experiment involving variable-argument smallest and greatest functions.

The important caveat is that splat is an incomplete, nightly-only experiment with no RFC. It may change substantially or disappear, so application teams should not treat it as a stable migration path. The Rust Foundation describes it as a mapping exercise: learn where the type system bends, where it resists, and what a later RFC should—and should not—promise.

For ICP and other Rust builders that depend on C++ libraries, the immediate action is limited: test representative bindings on nightly, record overload-resolution failures, and report concrete interop use cases. The larger signal is that Rust’s next FFI improvements may be measured by how well they preserve the maintenance model of the foreign library, not merely by how concise a generated binding looks.