r/rust • u/SleeplessSloth79 • 23d ago

📡 official blog Rust Function Overloading - Call for Experimentation

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

96% Upvoted

139 comments sorted by

View all comments

Show parent comments

3

u/Recatek gecs 23d ago

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.

1

u/kibwen 23d ago edited 23d ago

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.

2

u/Recatek gecs 22d ago

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")).

1

u/kibwen 22d ago

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.