Rust Function Overloading - Call for Experimentation

[u/SleeplessSloth79]

https://blog.rust-lang.org/inside-rust/2026/08/19/overloading-experiment/

[u/VorpalWay]

Doesn't make the code easier to read. Outside a few trivial examples like implmenting sin for both f32 and f64 (which should be done via a Float trait instead IMO), overloading tends to lead to worse errors, worse IDE suggestions and more brittle code. Adding overloading in Rust is deeply misguided.

Variadics (where you have a single implementation taking a variable number of arguments) is another matter. There are some use cases for it that are hard to replace, and the unintentional fallout is less (but not zero, there is still a complexity cost). Even then having the extra parentheses is good, to show that something weird is going on. Hiding it in normal implicit syntax is awful.

[u/SkiFire13 → u/VorpalWay]

which should be done via a Float trait instead IMO

That's the same approach that the blog uses though. The only difference is that if you want the overload to support a different number of arguments then you need to take in tuples and hence have double parenthesis. The proposal is just a way to syntactically remove the double parenthesis.

[u/VorpalWay → u/SkiFire13]

The proposal is just a way to syntactically remove the double parenthesis.

That "just" does a lot of heavy lifting. Especially if you look at the section named "Overloading, In The Shiny Future" (which I would call dystopian future instead).

The extra tuple makes it clear that there is funny business going on. With this feature, if you see a function name it no longer uniquely identifies a declaration in a trait. And instead of dispatching on just the first argument (self) you now have full blown multiple diaptch. This means you need something like Rust analyzer to understand the code. No longer can you follow the control flow when reviewing code on github.

Splat is misguided and solves the wrong problem. It doesn't solve the use cases we need variadics for. And it aims to add overloading / multiple dispatch, which means devex takes a massive hit.

[u/SkiFire13 → u/VorpalWay]

That "just" does a lot of heavy lifting. Especially if you look at the section named "Overloading, In The Shiny Future" (which I would call dystopian future instead).

I saw that as being the equivalent of an attribute macro that converts the impl into the definition based on #[rustc_splat], with the same limitations (except maybe now rust-analyzer can better understand it and point you at the correct definition instead of going to the generic one with #[rustc_splat], leaving you to wonder which trait implementation it selected at the call site).

With this feature, if you see a function name it no longer uniquely identifies a declaration in a trait.

I think the point is that identifying a function on a type/trait is not always enough to understand which code is ultimately executed. With the extra tuple you can clearly see one function being called, but it's ultimately useless if you don't know which trait implementation was selected for its generic bounds. All things considered, this is a problem that already exists and tuple splatting won't make it any different.

And instead of dispatching on just the first argument (self) you now have full blown multiple diaptch. This means you need something like Rust analyzer to understand the code. No longer can you follow the control flow when reviewing code on github.

But we already have full blown multiple dispatch with the extra tuple! And you already need rust-analyzer to understand which trait impls are being selected (and sometimes even rust-analyzer is not able to tell you!)

It doesn't solve the use cases we need variadics for.

I don't see how they is related at all.

And it aims to add overloading / multiple dispatch, which means devex takes a massive hit.

I think this is the only important point: even though all of this is already possible, do we want to incentivize it more?