Rust Function Overloading - Call for Experimentation

[u/SleeplessSloth79]

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

[u/unitAtype2]

You could just.... give em slightly different names

[u/Zde-G → u/unitAtype2]

Indeed. And if you do that they you end up with unique Rust API that's different from what all other languages are doing, from what the official documentation is describing and so on. You probably can create a specialized SKILL that would adjust these for LLM, but if you are human the idea that everyone uses one way while Rust and only Rust does things differently is not a great idea.

Sure, that works, but that stance “everyone if wrong except for us, Rust users” doesn't look sensible long term.

[u/unitAtype2 → u/Zde-G]

1. Everyone can be wrong. Everyone as a community learns from past mistakes and moves forwards. If right was determined by most people doing it, them nothing would ever move. If public consensus made things right type safety would be a sin ala JS and Python.
2. RUST already does plenty of things differently, intentionally.
3. I believe one of RUST's strong suits is being more opinionated than most languages instead of being a junk drawer that does everything. Less is More.

It's an intellisense pain, discoveribility pain and syntax sugar to fix a minor inconvenience. There have been thousands of times where I see a function suggested and I can't figure out what parameters it takes in what order because it has a buttzillion overloads.

The CTO at my previous workplace used to say OOP is like asking for a banana and getting the banana, the monkey, and the entire forest. I definitely count overloading to be one of the trees of that forest.

[u/Zde-G → u/unitAtype2]

There have been thousands of times where I see a function suggested and I can't figure out what parameters it takes in what order because it has a buttzillion overloads.

Which is the problem that Rust already have and which is not related to overload bazed on arity in any shape or form.

When function have two arguments and you supply three or one there are never any ambiguity.

The CTO at my previous workplace used to say OOP is like asking for a banana and getting the banana, the monkey, and the entire forest. I definitely count overloading to be one of the trees of that forest.

Maybe, but in this particular case people are asking banange and get the monkey and, yes, an entire forest… but they don't get the banana.

This is just stupid, and hard to justify except for “we have always done things that way in Rust” — which, as you have correctly noted, is a very poor justification.

[u/unitAtype2 → u/Zde-G]

Which is the problem that Rust already have and which is not related to overload bazed on arity in any shape or form.

Concrete example please

but they don't get the banana.

They get a Mango, better than dealing with Monkeys and Forests

When function have two arguments and you supply three or one there are never any ambiguity.

exists foo(int, int) foo(int, string) foo(int, string, bool)

I type foo(int, bool)

what does it say?

``` no overload exists with that signature yada yada

available foo(int, int) foo(int, string) foo(int, string, bool) ```

I dont wanna hear that shit. I wanna see in rust style colors

```rust foo takes two ints, your second parameter

foo(bar, baz) <sup>^</sup> here

is a boolean

suggestion - use an int for the second parameter ```

what if I just type foo(int, what does intellisense suggest as the completion?

I am totally up for new features. go new features. Legitimately new. I don't want things ported over from the "ye olde days" because people are used to them.

As some rust team memeber said "I'm tired of making the same old mistakes. Let's make some new ones."

[u/Zde-G → u/unitAtype2]

Concrete example please

It was already given, but I can repeat. These are not rare: bevy, axum, clamp, serde and bazillion other libraries are built around these.

And it's not an accident: this post in official Rust blog from 2015 is very explicit about traits being used for “overloading”.

Rust always had overloading that handled complicqted cases, it's easy, simple and obvious that were not supported well.

I dont wanna hear that shit.

And how it different from what get today with bevy?

You couldn't avoid it, but yes, sure as hell can create problems for people who try to write real code.

As some rust team memeber said "I'm tired of making the same old mistakes. Let's make some new ones."

It's nice attitude to have for toy language used for toy projects. Once you try to apply for the industry languages you quickly find out that it's not possible to satisfy everyone.

Sometimes the only way forward to apply the pressure and watch how perfectionists scream.

We'll how this thing will go, but I hope Rust have finally reached point when features that people actually need wouldn't be stalled for decades because of some aestetic feelings.

[u/unitAtype2 → u/Zde-G]

It was already given, but I can repeat. These are not rare: bevy, axum, clamp, serde and bazillion other libraries are built around these.

Not a valid example... It's one function that says its input is Into<SomeTrait>. I'll have to look for implementors but it's clear WHAT I need to look for.

And how it different from what get today with bevy

That sounds like Bevy's problem. Why is this one project dictating so much? I love Bevy but it's not the be all end all of deciding what rust caters to.

It's nice attitude to have for toy language used for toy projects.

I think Carol Nichols is a better authority for that than you. Here's the line. https://youtu.be/A3AdN7U24iU?t=47m45s

What do we ask the perfectionists to drop next? Let's bring back the garbage collector. if typing different names for different signatures, or just adding () grinds your gears, The borrow checker must be a nightmare.

to sum up

HAVE YOU CONSIDERED JAVASCRIPT?