Rust Internals explores named arguments and limited function overloading

Rust may get a little friendlier at the call site without giving up its habit of making data explicit. A pre-pre-RFC called splatting proposed `..args: Type` as the last parameter only, with call-site sugar that would turn named syntax into a structured argument object behind the scenes. The idea landed on Rust Internals on February 14, 2026 after growing out of a Zulip discussion about C++ overloading.

The sketch came in two flavors. In the struct-based version, `foo(a: 42, c: true, ..)` would desugar into a struct literal, so the function still received a concrete `Args` bundle instead of a bag of hidden magic. In the tuple-based version, `foo(42, "asdf".to_owned())` could work through a trait-based encoding of argument shapes, and the proposal said the feature could apply when the type is a struct or implements `std::marker::Tuple`. That keeps the promise of named-argument ergonomics while staying close to Rust’s preference for explicit parameter passing.

That is also where the thread got interesting. Replies from Nadrieril, RustyFrog, samsieber, scottmcm, gbutler, Vorpal, programmerjake and Aloso kept pushing on the same fault line: readability versus complexity. Supporters liked the idea for APIs with lots of optional knobs, where naming the important pieces at the call site can be clearer than building a temporary struct by hand. Skeptics worried about parser complexity, discoverability, and whether Rust really wants the maintenance burden that comes with overloading-heavy languages. The discussion also brushed up against FFI-style concerns and the broader question of how much flexible call syntax Rust should tolerate before it starts feeling like a different language.

This was not a new argument for Rust. Named-argument pre-RFCs showed up in 2016, 2018, 2020 and 2022, and the 2022 version was explicit that named arguments were in scope while default and variadic parameters were out. Earlier threads repeatedly tied named arguments to limited function overloading, and some participants argued those two ideas should be split apart rather than bundled together. That caution fits Rust’s RFC process, which is built to create consensus among stakeholders before the language takes on a substantial change.

The pressure for some kind of answer is visible in the ecosystem already. Crates on crates.io and docs.rs, including named, named_func_args, named_params and bon, keep simulating named-argument and builder-style APIs because library authors still want something cleaner than a giant hand-rolled configuration struct. That is the tension splatting laid bare: Rust wants easier calls, but it is still deciding how much hidden machinery it can add before the simplicity it is chasing disappears.