Rust’s Splat Experiment Puts Trait Coherence on the Call-Expression Hot Seat

Rust is testing a small-looking change with a large design surface: function arguments that are currently bundled into a tuple could be written as separate arguments at the call site. The experiment, called “splat,” is intended primarily for FFI bindings, where APIs in languages such as C++ commonly expose several functions with the same name but different parameter lists.

Today, Rust can approximate overloading with traits and tuples. A helper might accept an argument tuple and implement a trait for (f64, f64) and (f64, f64, f64), but callers must write an awkward form such as hypot((2.0, 3.0, 6.0)). The nightly experiment allows the helper to be called as hypot(2.0, 3.0, 6.0), while the compiler still uses Rust’s existing type inference and trait checking machinery.

That distinction matters. Splat is not yet a new C++-style overload resolver. The current design uses a tuple-shaped or generic parameter marked with the internal #[rustc_splat] attribute, and the feature gate is #![feature(splat)]. The call syntax is becoming more familiar; the underlying question is whether Rust’s type system can remain the authority when several foreign overloads compete.

The tracking issue makes that boundary explicit. It lists unresolved questions about trait coherence, overlapping overloads, whether overloads can be added by any crate, how optional arguments should work, which ABIs are eligible, and how same-named functions would receive distinct symbols. These are not cosmetic concerns: a convenient call expression is only useful if it still selects an unambiguous implementation and produces diagnostics developers can trust.

The experiment also has a broader target than C++. The Rust Foundation describes it as a mapping exercise for different FFI languages and API styles. The team wants evidence about where Rust’s existing rules bend easily, where they resist foreign conventions, and which parts should eventually live in macros, tooling, or the compiler. A future #[overload] design is presented only as a possibility, not as an accepted proposal.

For Rust developers, the practical advice is narrow. Mixed Rust/C++ toolchain authors and compiler contributors can test nightly builds from July 31, 2026 onward, exercise ambiguous and cross-crate cases, and report failures through the project’s interop channels. Application teams should treat this as design reconnaissance, not a migration target: there is no stable feature to enable and no promise that today’s syntax will survive.

Editorial caveat: splat is an incomplete nightly experiment with no RFC. Its syntax and behavior may change substantially or disappear, so the examples here should not be used as production or stable-Rust guidance.