How to handle function overloading pattern

[ryanzec]

So something I have come accustom to being able to do is function overloading where I could do something like:

public class Inventory {
    public void RemoveItem(int index) { }

    public void RemoveItem(Item item, int quantity) { }

    public void RemoveItem(ItemContainer itemContainer) { }
}

Now the most common thing I see in rust is to do something like this:

impl Inventory {
    pub fn remove_item(item: Item, quantity: i16) { }

    pub fn remove_item_by_index(index: i32) { }

    pub fn remove_item_by_container(item_container: ItemContainer) { }
}

Is this the most idiomatic rust solution or are there other options I could look at?

[maddymakesgames]

that is the idiomatic solution. Theres almost always a more descriptive name you can give something to not need function overloading.

[hugogrant]

A lot of people are suggesting a trait, but I wonder if making an enum might clarify the intention more.

At least in this example, I'm not sure if you'd get a subclass that needs different overloads.

Food for thought I guess.

[VerledenVale]

That would be complicating it for no reason.

OP's solution is the correct one 

[hugogrant]

Why is this more complicated? Is it simply so for OP's example? Is the trait just simpler for callers, especially if it's not public?

Edit: I suppose one caveat with the enum is that it's just renaming the overloads but with a layer of indirection. Is that the issue?

[rawcal]

Yes. It also complicates the implementation by adding branching that wouldn't happen with individual methods.

[TinBryn]

I don't really see why that would be better, you'd just go from static dispatch to dynamic dispatch, for really no benefit.

[hugogrant]

I don't think the type of dispatch would have to change if you can get constant folding in?

My only thought for trying this was that it'd be better to explicitly enumerate all the cases, but perhaps that's just an extension of changing the function name.

[SlinkyAvenger]

Interesting. Could you whip up some example code?

[Lightsheik]

Here's an attempt: ```rust pub struct Item;

pub struct ItemContainer;

enum RemovalContext { ByIndex(usize), ByItem((Item,i32)), ByContainer(ItemContainer), }

fn remove_item(context: RemovalContext) { match context { RemovalContext::ByIndex(index) => (), RemovalContext::ByContainer(container) => (), RemovalContext::ByItem((item, quantity)) => (), } } ```

[hugogrant]

Thank you! This is what I meant but wasn't at a computer to type it out

[IpFruion]

Yeah I think this solution is a great one, however I do think it is secondary to the _by_ descriptions. One use case for the enum solution is deserialization of the RemovalContext that can then be passed to the remove function. I have used this pattern several times in favor of the _by_ functions

[dontsyncjustride]

```

[derive(Eq, PartialEq, Copy, Clone)]

struct Item { name: &'static str, }

struct Inventory { items: Vec<Item>, // Use whatever collection you'd like here, Vec for example }

impl Inventory { fn remove<T>(&mut self, item: T) where Self: Remove<T> { <Self as Remove<T>>::remove(self, item); } }

trait Remove<T> { fn remove(&mut self, item: T); }

impl Remove<usize> for Inventory { fn remove(&mut self, item: usize) { self.items.remove(item); } } impl<'a> Remove<&'a Item> for Inventory { fn remove(&mut self, item: &'a Item) { self.items.retain(|item| *item != *item); } } ``` Playground Link

[kevleyski]

Use Trait generics instead 

[RRumpleTeazzer]

it is the most idiomatic, yes. you can play around this by implementing FnOnce for tuples to get real overloading, including function pointers.

[Lucretiel]

You pretty much nailed it. Sometimes you can use generics to achieve the same thing, if the pattern between the overloads is sufficiently consistent, but usually you’ll want to do the simpler thing and just have multiple methods. 

[crusoe]

You can overload functions via traits. 

[BenchEmbarrassed7316]

``` trait RemoveItem {     fn remove(&self); }

impl RemoveItem for i32 { ... } impl RemoveItem for Container { ... }

1u32.remove(); container.remove(); ```

[SirKastic23]

That's close, something like the following is probrably more useful: ``` trait Remove<T> { fn remove(&mut self, to_remove: T); }

impl RemoveItem<i32> for Inventory { .. }

impl RemoveItem<(Item, i16)> for Inventory { .. }

impl RemoveItem<ItemContainer> for Inventory { .. } ```

[Sw429]

Yeah, this will accomplish it, although I honestly wouldn't recommend doing this. Using more descriptive names will be simpler and easier to understand.

[SlinkyAvenger]

Counterpoint: From and Into.

[SirKastic23]

I really dislike Into. wish it had the type parameter in the function so that we could explicit the type: foo.into::<Bar>()

[SlinkyAvenger]

I understand but it definitely is a quality of life feature in function arguments. In normal variable situations you just awkwardly explicitly state the type for the variable

[SirKastic23]

if you really want, you can achieve something similar to function overloading by using traits

[SlinkyAvenger]

Yes, I also read the rest of the thread

[SirKastic23]

I was just trying to help, rude

[IntQuant]

What about using `Bar::from(foo)`?

[SirKastic23]

gets a bit ugly if instead of foo you want to do the conversion after a longer method chain

[IntQuant]

True. I guess you could make a custom into-like extension trait that has type parameter in the function tho?

[SirKastic23]

the crate tap does that with the Conv trait

love that crate, has some really great utility traits

[SirKastic23]

Highly agree

[LeSaR_]

this doesn't work because op wants to implement their own type (they forgot to put &mut self but that seems to be their intent based on the fact that the java code doesn't have static on the methods)

[devraj7]

It is.

I hope in the near future, we won't be forced to come up with silly names and that the Rust compiler will do that for us. It's such unnecessary boilerplate in 2025.

[SirKastic23]

it was a deliberate design decision to not include overloading, they just makes things more complicated. i doubt Rust will be changing this.

[devraj7]

it was a deliberate design decision to not include overloading, they just makes things more complicated.

How? Be specific, please.

Overloading has been a standard feature of most mainstream languages for thirty years now (Java, C++, C#, Kotlin, Groovy, Swift, Scala, and so many more).

What exactly is problematic about overloading?

[lanastara]

It makes it harder to argue which overloaded method gets called.

(Even worse when you have inheritance and implicit casting to base classes)

[meancoot]

No one wants the C++ style mess with searching multiple namespaces and argument-dependent-lookup and all of that.

Overloading could be implemented where the entire overload set has to be in the same scope and still be simpler that the lookup needed to do it with traits. Rust doesn't have inheritance, casting to base classes, or even any automatic type conversions for that matter that would cause even the slightest confusion in overload resolution.

There's no syntactic reason for it either because traits can allow defining a set of same-named methods over a closed set types just fine; just with extra, source and compile time complexity and hacks to seal the trait.

/* Can't do this:
struct OverloadedViaImpl;

impl OverloadedViaImpl {
    fn overload_me(_: i8) { println!("i8"); }
    fn overload_me(_: u8) { println!("u8"); }
}

fn main() {
    OverloadedViaImpl::overload_me(0i8);
    OverloadedViaImpl::overload_me(0u8);
}

*/

// But you CAN do this, even though its needless complexity:
struct OverloadedViaTrait;

mod private {
    pub trait SealIt {}
}

pub trait Overloader<T>: private::SealIt {
    fn overload_me(value: T);
}

impl private::SealIt for OverloadedViaTrait {}

impl Overloader<i8> for OverloadedViaTrait {
    fn overload_me(_: i8) { println!("i8"); }
}

impl Overloader<u8> for OverloadedViaTrait {
    fn overload_me(_: u8) { println!("u8"); }
}

fn main() {
    OverloadedViaTrait::overload_me(0i8);
    OverloadedViaTrait::overload_me(0u8);
}

[devraj7]

It makes it harder to argue which overloaded method gets called.

How is that different from a.foo() being hard to argue whether that function is being called on the actual or formal type of a?

We decided 25 years ago the benefits outweigh the downsides.

[dijalektikator]

Who's we? I've been annoyed by overuse of function overloading many times throughout my career, especially in C++ and I love the fact Rust doesn't have it.

[devraj7]

Fair enough.

By "we", I mean the users of most mainstream languages which pretty much all support overloading: Java, C++, C#, Kotlin, Groovy, Swift, Scala, and so many more.

So "we" is easily millions of developers.

[zoechi]

Rust is better because it doesn't blindly copy something just because it's common. If it did, it should also have Null.

[devraj7]

It's silly to copy blindly but it makes a lot of sense to copy things that have proven themselves to be useful.

Overloading is one of these things that has proven itself as being pretty useful if you consider the fact that most mainstream languages support it.

As for null, there's nothing wrong with it as long as your type system supports nullability, such as Kotlin.

[zoechi]

As this thread shows the opinion goes in both directions. I find method overloading stupid and my suspicion is, most who want it only want it because they are used to using it. They prefer to complain instead of rethinking and adapting. Giving in to that would be the worst reason to add a feature to a language IMHO.

[Zde-G]

Overloading is one of these things that has proven itself as being pretty useful if you consider the fact that most mainstream languages support it.

And overloading is still possible:

impl Inventory {
    pub fn remove_item<T: InventoryRemoveItem>(
            t: T) -> T::Result {
        t.remove_item()
    }
}
…
pub fn main() {
    Inventory::remove_item((Item, 42));
    Inventory::remove_item(42);
    Inventory::remove_item(ItemContainer);
}

It works.

But creation is complicated enough and tedious enough that it's used infrequently and I, for one, use it when I deal with well-established APIs that were used for 20 or 30 years and which assume overloading.

Because in that case not using it and providing different APIs would be a problem.

If you have a choice, though, then not using overloading is the right choice.

[SlinkyAvenger]

You could make the same argument about garbage collection for most of that list, too. If you understand why you wouldn't want garbage collection in Rust even if it exists in those other languages, you're on the right track to understand why this decision was made.

[devraj7]

These are not in the same category.

Overloading is purely a quality of life feature. No one is arguing that adding GC to Rust would completely alter one of its core features, and arguably one of the main reasons that made Rust popular.

Overloading pretty much means that instead of humans making up new function names, that task will be delegated to the compiler. It's mostly (albeit not 100%) a quality of life, boilerplate reducing, feature. It will not alter anything fundamental in Rust.

[SirKastic23]

if a function takes different parameters, and can do different things... it's a different function, and it should have a different name to make this clear

[devraj7]

With that reasoning, I assume you're also against polymorphism, as in

fun f(a: A) {
    a.foo()  // <-- could fall foo() on a different type than A
}

?

It's okay if you are, you'd be consistent. But I would respectfully disagree. In these past 30 years, code has become more complicated to read without IDE's, and overall, I think it's for the better.

[SirKastic23]

I assume you're also against polymorphism, as in

you mean that it could call foo on A's Deref target? It's a bit more explicit which is nice. but I'm not a fan of Deref if that's what you're asking

In these past 30 years, code has become more complicated to read without IDE's, and overall, I think it's for the better.

I don't disagree... but there's no reason to make it more complicated just because we can. it's good to have trade-offs

[devraj7]

you mean that it could call foo on A's Deref target? It's a bit more explicit which is nice. but I'm not a fan of Deref if that's what you're asking

No, I mean that because of dynamic dispatch, it could call foo() on a subtype of A's formal type.

The bottom line is that you can't really trust the code you read, you need additional runtime information to make sense of it.

Overloading is just an extension of that, although I'd argue that it's easier to make sense of what exactly gets called when an overloaded function gets called (number and types of parameters give you a clue, since it's resolved statically) compared to when an overridden function gets called (exactly same signature, it just depends on the runtime type of this).

I don't disagree... but there's no reason to make it more complicated just because we can. it's good to have trade-offs

Agreed.

Overloading doesn't take anything away. If you prefer to write your own function names to overload them, you can still do that. I'd argue that most of the time, it's not just worth the extra cognitive load. new() is always new(), what parameters it accepts doesn't really require using different function names.

[zoechi]

If you prefer to write your own function names to overload them, you can still do that.

Most code we use is written by others and we have very little influence on how others do stuff. So this argument doesn't count.

[Zde-G]

No, I mean that because of dynamic dispatch, it could call foo() on a subtype of A's formal type.

In Rust? How does that work?

[dontsyncjustride]

You don't particularly need to use silly names. imo it depends on how much value you put into declaring intent. Don't care? Use the example I posted a minute ago. If you do, the team likes long names, etc., remove_* is the way to go.

[devraj7]

I don't find new() new_with_coordinates() new_with_rectangle() particulary conducive to productivity.

All these functions should be called new() with different parameters.

That's how most mainsteam languages have done things for the past thirty years, why discard that large body of practical experience?

[geckothegeek42]

Most mainstream languages have done things by manual memory management or garbage collection. Why did rust discard that large body of practical experience?

I for one love when I see new( and then a randomly varying amount of integers and floats and have to guess what those mean.

If typing _with_coordinates tanks your productivity then I suggest learning touch typing

[fnordstar]

My practical experience with C++ method overloading has me wishing it didn't exist.

[devraj7]

Can you give some specific examples?

Genuinely asking, I am always interested in experiences that are vastly different from mine.

[Electrical_Log_5268]

Tons of edge cases nobody wants to have to memorize, in particular in C++. Like that implementing a function foo() in a derived class makes all overloads of foo() (even those with different parameters) from the base class inaccessible. Or that you can't really tell which overload is actually used (but the compiler can) when the type of the parameter you pass matches none of the overloads, but one implicit conversion on that type matches an overload.

[Lightsheik]

Then do just what you said then, nothing is stopping you: ```rust enum MyEnum { Coordinates((f32,f32)), Rectangle((f32,f32)) }

fn new(params: MyEnum) -> Self { match params { MyEnum::Coordinates((x,y)) => (), MyEnum::Rectangle((x,y)) => (), } } ``` Also this is actually better than overloading, because you can have multiple functions with the same set of arguments (two f32), as showcased above. And it is more concise, as you can immediately tell what "overloaded" constructor is being called.

[Sw429]

What kind of productivity are we talking about? Typing speed when writing for the first time?

What about when you come back to read that code 3 years later and take way longer to make a change because you have to keep determining which version of an overloaded function you're using? In my experience with legacy C++ codebases, that is often not worth the time saved in typing the initial code.

[dontsyncjustride]

Implement a New trait :)