--- title: Rust Function Overloading - Call for Experimentation description: The Rust Project, in partnership with the Rust Foundation's Rust-C++ Interop Initiative, is experimenting with an unstable nightly feature called "splat"... canonical: https://daily.dev/posts/rust-function-overloading---call-for-experimentation-fygog582p twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Rust Function Overloading - Call for Experimentation | daily.dev og:description: The Rust Project, in partnership with the Rust Foundation's Rust-C++ Interop Initiative, is experimenting with an unstable nightly feature called "splat"... og:url: https://daily.dev/posts/rust-function-overloading---call-for-experimentation-fygog582p og:image: https://api.daily.dev/og/posts/fYGOG582p.png og:image:alt: Rust Function Overloading - Call for Experimentation og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Rust Function Overloading - Call for Experimentation **[Inside Rust Blog](https://daily.dev/sources/insiderustblog)** · 7 min read · 3 upvotes · 0 comments ## Summary The Rust Project, in partnership with the Rust Foundation's Rust-C++ Interop Initiative, is experimenting with an unstable nightly feature called "splat" (#[rustc_splat]) that enables more ergonomic function and method overloading, aimed primarily at simplifying FFI bindings to languages like C++. Available on nightly builds from 2026-07-31 onwards, splat lets overloaded functions be called with separate arguments (e.g. hypot(2.0, 3.0, 6.0)) instead of requiring a tuple. The feature is incomplete, unergonomic, and has no RFC yet; recent merges add splat support in rustdoc and for function pointers. Compiler and interop tool developers are invited to experiment and report bugs via the #t-lang/interop Zulip channel. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How does the new splat feature in nightly Rust let you call overloaded C++ functions differently from stable Rust's tuple-based overloading? Splat, enabled via the unstable #[rustc_splat] attribute, lets overloaded functions be called with separate arguments like hypot(2.0, 3.0, 6.0), instead of stable Rust's tuple syntax hypot((2.0, 3.0, 6.0)). It is available only on nightly builds from 2026-07-31 onward, has no RFC, type-checks like a stable overload, and can change or be removed at any time. _Developers tracking experimental Rust FFI features like splat overloading can follow updates on daily.dev._ ### What is the #[rustc_splat] attribute used for in Rust's function overloading experiment? The #[rustc_splat] attribute marks a tuple-typed argument so it can be called as separate arguments instead of a single tuple, enabling more ergonomic function overloading for FFI bindings, particularly for calling C++ functions like hypot from Rust. It is part of an incomplete nightly-only compiler feature with no stability guarantees, aimed at exploring interop use cases before any RFC. _Anyone experimenting with Rust FFI overloading can keep tabs on the feature's evolution through daily.dev._ ### Is Rust's function overloading feature for FFI stable enough to use in production code? No, splat-based function overloading is an incomplete, nightly-only compiler feature with no RFC that can change or be removed at any time. It requires the unstable #[feature(splat, tuple_trait)] flags, and even recently added support (like rustdoc display and function pointer splatting) is explicitly marked unstable and subject to change. _Teams weighing whether to adopt experimental Rust interop features can track stability signals on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 19 comments across lobsters (as of 2026-09-14). **TL;DR:** Discussion centers on whether Rust needs overloading at all, with many arguing existing trait-based generics already cover type-based dispatch and that true overloading (by argument count/defaults) risks C++-style ambiguity and hurts greppability, while others say the real gap is named/default arguments or that limited overloading works fine in other languages. **Sentiment:** 15% positive · 45% mixed · 40% skeptical **The case for** - Some argue overloading works well enough in languages like C#, Java, and Ada without major problems. - Named methods for every argument variation create longer, awkward names and mental overhead that overloading could reduce. - One commenter notes traits already permit type-based dispatch, so the type system already tolerates some polymorphism. **The pushback** - Several worry overloaded dispatch based on argument count/type will hurt greppability and make it unclear which implementation runs. - C++'s overloading combined with implicit conversions and templates is cited as a source of confusing error messages and hard-to-trace behavior. - Some fear this feature, though meant for C++ FFI, will get abused in pure Rust code that has nothing to do with interop. - One commenter questions whether FFI ergonomics alone justifies such a deep language change, suggesting existing name-mangling tools (e.g. cxx) already solve it. - Rust's tooling/readability strength is said to come partly from the *absence* of overloading, unlike C#/Java where strong IDEs compensate. **By community** - lobsters (mixed): A long back-and-forth debates whether traits already solve type-based overloading and whether argument-count overloading is worth the readability risk, with sentiment split between cautious interest and firm skepticism. **Hottest debate:** Whether Rust's existing trait system already provides sufficient overloading-like polymorphism, making a dedicated overloading feature unnecessary or even harmful. **Open questions** - Where should the line be drawn between acceptable trait-based polymorphism and explicit function overloading? - Should keyword/named arguments and defaults be prioritized over general overloading? - Is FFI ergonomics alone sufficient justification for adding such a deep, general-purpose language feature? **Highlights** > I actually hope this doesn't become more ergonomic, or at least, not for Rust code. Overloading is a huge pain in the side of C++ codebases where it's unclear of the function's behavior just looking at the arguments being passed in, even if you're familiar with the function(s) that can be called. It's one of the explicitness items of Rust I really appreciate. This feels like it's going to be abused quite a bit despite being for C++ primarily, in code that doesn't touch C++ at all. > — [junon on lobsters · 1 points, 2 comments](https://lobste.rs/s/rikfb5/rust_function_overloading_call_for#c_szt0oj) > Lack of overloading is one of the things that annoys me about Rust syntax. It’s not unusual for a type to have multiple methods that do conceptually the same thing but take different arguments. With overloading you can name the single “thing”, the operation, but have overloads for the different cases. Without it, you have to give each set of arguments its own method name, and then the programmer has to remember all those names and which does which. This results in longer (often awkward) names, and more mental overhead. > — [snej on lobsters · 1 points, 1 comments](https://lobste.rs/s/rikfb5/rust_function_overloading_call_for#c_d5btfq) > > I really do not want a world in which a callee's implementation can change based on the number or type of arguments the caller passes: it massively hurts greppability. I think it's complicated. For you the issue might be the number of arguments, but today's Rust code already allows you to dispatch based on type and we seem to be fine with it? (as in you can have one function that is overloaded based on the type of argument). ```rust trait Do { type Output; fn do_something(self) -> Self::Output; } impl Do for &str { type Output = String; fn do_something(self) -> String { let rv = self.to_uppercase(); println!("{rv}"); rv } } impl Do for i32 { type Output = i32; fn do_something(self) -> i32 { let rv = self.pow(2); println!("{rv}"); rv } } fn do_something(value: T) -> T::Output { value.do_something() } fn main() { let text: String = do_something("hello from rust"); let number: i32 = do_something(12); println!("String length: {}", text.len()); println!("Squared number plus one: {}", number + 1); } ``` > — [mitsuhiko on lobsters · 1 points, 1 comments](https://lobste.rs/s/rikfb5/rust_function_overloading_call_for#c_ckotcb) > I agree they work fine in those languages. That being said. 1. At least for C# and Java, the tooling there is immensely good since the languages are a bit simpler (than C++) and we're more or less built with tooling / IDEs in mind. 2. This is Rust<->C++ in particular, which is a nightmare scenario given C++ tooling itself is lackluster (and has been for decades). Rust code can, for the most part, be written without an IDE, assuming you have docs available. All languages can of course, but the efficiency gains you get from C# and Java stem from tooling, whereas in Rust it's the compiler and its errors. This is in _large part_ because Rust doesn't require you track down conditionally-implemented types; you can almost always track figure out what's happening, exactly, based on the file alone. Traits muddy this property a bit but the defacto culture of naming traits based solely on what they do helps. Otherwise, the lack of overloading is doing a lot of heavy lifting in terms of readability. > — [junon on lobsters · 1 points](https://lobste.rs/s/rikfb5/rust_function_overloading_call_for#c_slbmve) > I'm kind of confused. Is this for c++ FFI specifically? If so, what's wrong with explicitly name mangling exports? The `cxx` crate and i think others have utilities to make it easy. I don't think FFI ergonomics is a strong enough justification for a language feature this deep. I personally kind of like that rust doesn't have overloading, in C++ I'm never sure i'm looking at the right implementation because of it. Between macros and Into/From i think we've got a better dispatch mechanism for everything overloading does well. > — [landon on lobsters · 4 points](https://lobste.rs/s/rikfb5/rust_function_overloading_call_for#c_p7xalq) **Source threads** - [lobsters](https://lobste.rs/s/rikfb5/rust_function_overloading_call_for) · 28 points · 19 comments ## Similar posts on daily.dev - [Rust/C\+\+ Interop Initiative: Progress Update, September 2026](https://daily.dev/posts/rust-c-interop-initiative-progress-update-september-2026-j7c1j8xac) · Rust Foundation · 1 upvotes · 0 comments - [Rust language adds algebraic floating-point methods](https://daily.dev/posts/rust-language-adds-algebraic-floating-point-methods-jimyxkos8) · InfoWorld · 1 upvotes · 0 comments - [Faster floating point math with Rust’s new API](https://daily.dev/posts/faster-floating-point-math-with-rust-s-new-api-zyoed6fm9) · Lobsters · 0 upvotes · 0 comments - [We Have Named Arguments at Home](https://daily.dev/posts/we-have-named-arguments-at-home-rkawezkub) · corrode · 3 upvotes · 0 comments --- Tags: [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/rust-function-overloading---call-for-experimentation-fygog582p) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Rust Function Overloading - Call for Experimentation","url":"https://daily.dev/posts/rust-function-overloading---call-for-experimentation-fygog582p","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/rust-function-overloading---call-for-experimentation-fygog582p"},"datePublished":"2026-08-19T15:51:22.871Z","dateModified":"2026-09-14T08:37:05.667Z","description":"The Rust Project, in partnership with the Rust Foundation's Rust-C++ Interop Initiative, is experimenting with an unstable nightly feature called \"splat\"...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/10c030b2429f801a5aed8756bdece9d2?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/10c030b2429f801a5aed8756bdece9d2?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Inside Rust Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Inside Rust Blog","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/dac5ded91c53479ba19948cc58333757","url":"https://daily.dev/sources/insiderustblog"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/rust-function-overloading---call-for-experimentation-fygog582p","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"rust","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Inside Rust Blog","item":"https://daily.dev/sources/insiderustblog"},{"@type":"ListItem","position":3,"name":"Rust Function Overloading - Call for Experimentation"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/rust-function-overloading---call-for-experimentation-fygog582p#faq","mainEntity":[{"@type":"Question","name":"How does the new splat feature in nightly Rust let you call overloaded C++ functions differently from stable Rust's tuple-based overloading?","acceptedAnswer":{"@type":"Answer","text":"Splat, enabled via the unstable #[rustc_splat] attribute, lets overloaded functions be called with separate arguments like hypot(2.0, 3.0, 6.0), instead of stable Rust's tuple syntax hypot((2.0, 3.0, 6.0)). It is available only on nightly builds from 2026-07-31 onward, has no RFC, type-checks like a stable overload, and can change or be removed at any time. Developers tracking experimental Rust FFI features like splat overloading can follow updates on daily.dev."}},{"@type":"Question","name":"What is the #[rustc_splat] attribute used for in Rust's function overloading experiment?","acceptedAnswer":{"@type":"Answer","text":"The #[rustc_splat] attribute marks a tuple-typed argument so it can be called as separate arguments instead of a single tuple, enabling more ergonomic function overloading for FFI bindings, particularly for calling C++ functions like hypot from Rust. It is part of an incomplete nightly-only compiler feature with no stability guarantees, aimed at exploring interop use cases before any RFC. Anyone experimenting with Rust FFI overloading can keep tabs on the feature's evolution through daily.dev."}},{"@type":"Question","name":"Is Rust's function overloading feature for FFI stable enough to use in production code?","acceptedAnswer":{"@type":"Answer","text":"No, splat-based function overloading is an incomplete, nightly-only compiler feature with no RFC that can change or be removed at any time. It requires the unstable #[feature(splat, tuple_trait)] flags, and even recently added support (like rustdoc display and function pointer splatting) is explicitly marked unstable and subject to change. Teams weighing whether to adopt experimental Rust interop features can track stability signals on daily.dev."}}]} ```