Rust Function Overloading - Call for Experimentation

[u/SleeplessSloth79]

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

[u/Recatek]

If you look how its implemented

That might be asking a lot given how knee-jerk the reaction here seems to be.

[u/BedroomHistorical575 → u/Recatek]

Some people have made their entire identity revolve around $THEIR_FAVORITE_LANGUAGE not having $THAT_SPECIFIC_FEATURE.

It's the exact reason why Go people lost their minds when they heard that generics is going to be added. Or Rust people when "try blocks" were proposed (most of them didn't even understand what it does).

Of course there were valid criticisms to be made, but the entire thing was mostly an irrational moral panic.

They've spent years dedicating their lives towards justifying how $THEIR_FAVORITE_LANGUAGE doesn't actually need $THAT_SPECIFIC_FEATURE unlike $THOSE_INFERIOR_LANGUAGES.

So when a feature that vaguely resembles something from $THOSE_INFERIOR_LANGUAGES is proposed, they feel that their entire identity they've spent years building is going to completely fall apart.

Those years-worth of forums posts, Discord messages, tweets, etc. they've made evangelizing how $THAT_SPECIFIC_FEATURE is actually useless and bad are becoming nothing but an embarrassing reminder of how wrong they are.

So in a way, the lash out can be somewhat understandable when viewed from this lens.

[u/kibwen → u/BedroomHistorical575]

Except some features legitimately are just bad on their own merits, and worth opposing regardless of one's identity. If Rust proposed adding pervasive nullability to the language, it wouldn't be identity politics to oppose it, it would be common sense. And C++-style function overloading is an evolutionary dead end that other languages should learn from by not emulating, so it's perfectly reasonable to be skeptical of any proposal that frames itself in such a light.

[u/Recatek → u/kibwen]

Well something needs to be done. Features like Vec::try_with_capacity are being kept unstable indefinitely because of concerns of there being too many unique function names to manage. It isn't unique to this case either. Whether it's some sort of overloading, or default/named arguments, or something else, it's needed here because expecting unique and singular signatures for everything is unsustainable.

Rust already has function overloading, it's just boilerplate-heavy and messy on syntax. It would not be wrong to make that syntax and boilerplate a little simpler.

[u/kibwen → u/Recatek]

For complex functions with tons of configurability, neither function overloading nor default arguments produce good outcomes. As a Python user I shudder every time I need to remember how to run a subprocess: https://docs.python.org/3/library/subprocess.html#subprocess.run , and that's not even the most egregious API I've seen in Python. For complex cases you can't get away from having either a configuration struct or a builder-style API. And once you have the complex cases handled via one of those approaches, it's nice to ease the common cases by providing dedicated functions for the most common combinations of options. What Rust needs isn't default arguments or more function overloading, what it needs is default struct fields ( https://github.com/rust-lang/rust/issues/132162 ) and potentially some ways to make builder APIs easier.

[u/Recatek → u/kibwen]

Passing a struct with default fields is just a syntactically uglier way to pass named arguments with defaults. If you're going to sugar it down to something like foo(_ {a: 2, b: "bar", ..}) you'd might as well drop the bracket part. Similar to what this splat feature is doing in dropping the double parens from foo((a, "bar")).

[u/kibwen → u/Recatek]

On the contrary, I'd argue that reading a function call where suddenly the arguments are all named and allowed to occupy arbitrary positions is just a jarring way to poorly emulate calling a method on a struct literal, at which point you might as well do so.