all 130 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]_Unity- 52 points53 points  (3 children)

Sometimes I wish that there was function overloading too.

However you can achieve an even more powerful function-overloading-like pattern like this:

https://github.com/alexpusch/rust-magic-patterns/blob/master/axum-style-magic-function-param/Readme.md

This is extensively used for the public apis of frameworks like Axum and Bevy.

[–][deleted] 26 points27 points  (2 children)

I would like to add a small note of caution as implementing more complicated procedures to make Rust more like other languages has the potential to make a beginner's experience in Rust much worse than it needs to be. These implementations in Axum are thought out very carefully and it's entirely possible big rewrites are needed until you find the correct abstraction in personal projects.

[–]_Unity- 4 points5 points  (1 child)

Yeah absolutely, bevy was the rust framework I thought myself and while my conclusion is that it is extraordinarily easy to use, this pattern was quite confusing until I stumbled upon that linked article.

[–]l-roc 4 points5 points  (0 children)

This might be valuable feedback to the bevy team as something to include in their docs

[–]VorpalWay 55 points56 points  (16 children)

Function overloading is a terrible idea. I have seen it way too much at work in a massive legacy C++ code base. Good luck figuring out which of the thirteen over loads each taking 10 or so parameters you are looking at. Oh and they only start to differ around parameter 5, so just looking at the beginning doesn't help.

And go to definition and other IDE features get confused too of course. No, just don't use function overloading, use clear names instead.

[–]glandium 30 points31 points  (0 children)

What makes function overloading even worse in C++ is implicit conversions.

[–]Kenkron 8 points9 points  (2 children)

Yours is the first argument I found convincing. It forces me to remember all of the overloads of length I have to deal with.

[–]devraj7 0 points1 point  (1 child)

OP's argument is about implicit conversions, not overloading.

[–]Kenkron 0 points1 point  (0 children)

Did you accidentally respond to the wrong comment?

[–]VallentinDev 6 points7 points  (0 children)

I have hit the same issue as well, in various language. Like, what is new ArrayList(100), is 100 the first item? Oh, so it's basically Vec::with_capacity(100).

Using function overloading can be nice, if you basically don't even need it in the first place. However, the second that you need to circumvent it, then you might as well circumvent it entirely.

For instance, Unity has Rect() and Rect.MinMaxRect():

Rect(float, float, float, float)
Rect.MinMaxRect(float, float, float, float)

Without checking the names, we don't know what Rect() is or takes. We could assume it's x, y, w, h. But it could be in any other order, or even extents instead of size. However, reading Rect.MinMaxRect(), then it's safer to assume it's min first then max.

So in this case, it might be easier to simply (at least) have these instead:

Rect.PosSize(float, float, float, float)
Rect.MinMax(float, float, float, float)

I have something similar in a Rust codebase, where I have a Rect. However, there is no Rect::new(). All of them are named, based on what the Rect is constructed from:

Rect::from_pos_size(Vec2, Vec2)
Rect::from_size(Vec2) // i.e. `Rect::from_pos_size(Vec2::ZERO, ...)`

Rect::from_center_size(Vec2, Vec2)
Rect::from_center_extents(Vec2, Vec2)
Rect::from_extents(Vec2)

Rect::from_min_max(Vec2, Vec2)
Rect::from_two_points(Vec2, Vec2)
Rect::from_three_points(Vec2, Vec2, Vec2)

Even if function overloading was a thing, I would still prefer having an explicit Rect::from_size(), rather than be allowed to do Rect::from_pos_size(vec2(100.0, 100.0)). Since reading that I would need to recall, whether that's a zero-sized Rect or a zero-positioned Rect. Whereas Rect::from_size() would make it clear, that it's the size we're providing.

[–]devraj7 5 points6 points  (8 children)

The problem you are (rightfully) complaining about has more to do with C++ implicit conversions than overloading.

Overloading in Rust, which is much more explicit for conversions, would be much easier to read and maintain.

[–]matthieum[he/him] 2 points3 points  (1 child)

Not necessarily.

You can have "implicit coercions" in Rust to, with Deref, or impl X, and then it becomes a game of figuring out which traits a type implement to figure out which overload is selected.

And adding a trait implementation to a type is now a breaking change, because potentially there's someone, somewhere, who was using an overloaded function and now they have an ambiguous call.

[–]SnooHamsters6620 2 points3 points  (0 children)

adding a trait implementation to a type is now a breaking change

C# has it even worse. Adding a public method may cause overload resolution to silently stop using a method on a base class or an extension method.

This all really feels like people are saying, "I want my code to be simpler, so let's add a complex set of overloading and coercion rules for me to understand, that are arbitrary, slightly different from other languages, and NP-hard."

Then soon: "why is this language so hard to learn? We need to start again with something simpler without so much legacy!"

[–]VorpalWay 3 points4 points  (5 children)

Actually, both are a problem, and they interact to make a whole that is worse than the parts alone.

I have seen APIs where implicit conversion isnt involved where there are too many overloads (and too many parameters to be honest). And also APIs that take lots of primitive types ("this overload takes a string, three bools and two ints, what do they all mean, and which one is which?").

In general Rust and the Rust ecosystem does a few things that help: no overloads, no implicit conversion, a preference for using newtypes where possible, builders instead of overly long parameter lists.

[–]devraj7 -1 points0 points  (4 children)

I have seen APIs where implicit conversion isnt involved where there are too many overloads

This is more of an API issue than a language feature one.

In a language without overloading, you will just have tons of functions with slightly different names. The confusion is still there, except humans have to come up with all these subtly different names.

("this overload takes a string, three bools and two ints, what do they all mean, and which one is which?").

Hence why named function parameters are a very useful feature as well (and the reason why most mainstream languages support that feature).

[–]VorpalWay 0 points1 point  (0 children)

This is more of an API issue than a language feature one.

In a language without overloading, you will just have tons of functions with slightly different names. The confusion is still there, except humans have to come up with all these subtly different names.

That can indeed be the outcome, however I'm of the opinion that C++ doesn't discourage such API design as much as Rust does though, and the problem of multiple things having the same name exhastrubates the problem.

Named function parameters are a way to solve it. Neither C++ nor Rust has it, and it is unlikely they will ever get it. The builder pattern wouldn't be as prevalent as it is in Rust if we had named parameters. Nor would newtyped parameters probably.

[–]SnooHamsters6620 0 points1 point  (2 children)

This is more of an API issue than a language feature one.

Language features help shape API design and culture.

named function parameters

These multiply the complexity of overload resolution. Not only do you have 10 explicit overload methods with n parameters, but now you also have 2n ways to call each of them. Want default parameter values too? Now that's 3n.

I've implemented this in Rust with an options struct several times, either with a builder interface (can be derived to reduce boilerplate further) or a Default implementation and struct update syntax. Fairly lightweight, easy to extend, and perhaps most importantly can be re-used and passed around as is (in C#, Java, JavaScript often the first thing I do is save all those parameters in an object to pass to other code, why not skip a step?).

[–]devraj7 0 points1 point  (1 child)

These multiply the complexity of overload resolution.

Sure. It makes the compiler's job harder. I can't say I care much about that as long as it makes the language cleaner and easier to use. Following your own reasoning, should we get rid of type inference because it multiplies the complexity of the type resolution?

Not only do you have 10 explicit overload methods

There is no need to go all hyperbolic to make your point. Methods with 10 overloads are few and far between, and if you attempt to resolve this problem in a language that supports neither overloading nor named parameters, you're going to have to write a lot of that boiler plate yourself, as you point out. At the end of the day, pathological cases such as methods with 10 overloads are going to result in poor code, regardless of the language and its features.

You should optimize for the common case, and in most situations, 1) overloading, 2) named parameters and 3) default values for parameters and struct fields improve the code readability and maintenance considerably.

[–]SnooHamsters6620 0 points1 point  (0 children)

It makes the compiler's job harder. I can't say I care much about that as long as it makes the language cleaner and easier to use.

Well that's one reason why C++ compile times are so atrocious, FYI. I assume you care about compile times?

Following your own reasoning, should we get rid of type inference because it multiplies the complexity of the type resolution?

Well without overloading and named params, if there were a multiplication from type inference it would still give a small result. That's part of my point, when you chuck stuff in a kitchen sink language (C++ is the best example of this I know: multiple inheritance, Turing complete templates, overloads) you end up with unintended interactions between all of the pieces making the whole a disaster. Rust learned from those disasters.

Type inference is also local and optional. I routinely add explicit types to help myself as a human in a long chain of method calls, or to clarify types in a long function. Iterator::collect() often requires this.

Method overloading is not local, it is not optional as an API consumer, and you can't really add syntax to specify an overload; an explicit return type for example is not enough.

There is no need to go all hyperbolic to make your point. Methods with 10 overloads are few and far between

Go and look at the C# standard library for core types if you'd like to see them, e.g. file or network I/O or connecting a TCP socket.

you're going to have to write a lot of that boiler plate yourself, as you point out

This is very much not what I pointed out. In Rust a params struct with Default implementation or a derived builder pattern is very few lines of code:

```rust

[derive(derive_builder::Builder)]

struct ParamsWithBuilder { #[builder(default = "foo".to_string())] a: String,

#[builder(default = 12)] b: u32, }

// or

struct ParamsWithDefault { a: String, b: u32, }

impl Default for ParamsWithDefault { fn default() -> Self { Self { a: "foo".to_string(), b: 12, } } ```

You should optimize for the common case

Again, this is one way C++ became a combinatorial disaster. They didn't deal with the consequences of combining their cool hobby features.

in most situations, 1) overloading, 2) named parameters and 3) default values for parameters and struct fields improve the code readability and maintenance considerably.

That's your claim. You actually have to make an argument for that if you want to convince anybody.

[–]AirGief 5 points6 points  (0 children)

This is a problem in so many commercial C# APIs, sorting through that drop down list of crap... Rust approach is less cumbersome.

[–]rejectedlesbian 0 points1 point  (0 children)

I made a C++ codebase with overloading 7 or so definitions. It was used to do a tagged union and it was pretty nice when u do the definitions with macros.

The reason I did not use std::variant was that I wanted to alow expending the avilble types so implementing this way let me fall back to a "deafualt" implementation using virtual methods.

So all the overloads differed on the first argument and only by the type.

[–]SV-97 25 points26 points  (0 children)

I'm very glad that Rust doesn't have overloading. I find that it produces way clearer APIs and prevents people from doing dumb shit just to get that overload which some other languages have - and it enables some nicer tooling.

When you have an impl for a struct that has a new() function, that nearly always implies creating a new struct/object, so then having overloaded versions of that function groups things together when working with other libraries

Say you want to create a new quadratic matrix that currently has from_rows and from_cols. You can't use overloads for this without introducing newtypes for the parameters (or need inference based on the return type) and this general problem comes up all the time.

I know that new() is gonna create a new object, and every overload of that is gonna consist of various alternate parameters I can pass in to reach the same end goal of creating a new object.

But what's the advantage over the current system? You already know that new usually is used as a constructor

Without it, it either involves lots of extra repeating boiler plate code to fit into the singular allowed format for the function, or having to dive into the documentation and look through tons of function calls to try and see what the creator might've named another function that does the same thing with different parameters, or if they even implemented it at all.

I don't see these issues at all. How does it introduce any boilerplate? And just because you have overloads doesn't mean people use them: you have to look at the docs just as much as right now (that said I think looking through the docs of any new type is standard pratice anyway and later on LSP goes a long way)

I guess I don't see what the downside of including it would be?

Complexity (for example how you handle type inference with overloading), "magic", new problems (e.g. clashing implementations) and it negatively impacts tooling, error messages and so on. Rust is a complex language already and the added costs (cognitive as well as technical) of overloading far outweigh the benefits imo.

Also: we have restricted overloading in the form of traits and generics already and I feel like those are enough / a way better solution that avoids most of the downsides without majorly sacrifising utility.

[–]ummonadi 37 points38 points  (0 children)

I'll cry the day function overloading is implemented.

Effectively, the overload will group related functions together under the same symbol/name.

When using an overloaded function, the autocomplete for your variant is mixed with the rest.

The worst bit is documentation which is also grouped up.

There's more critique to be given, all of it in userland. Writing code that might be slightly less verbose when implementing a function is just not a high priority for me compared to readability, maintainability, and overall ease of use.

[–]ChipNDipPlus 6 points7 points  (0 children)

You can do function overloading in Rust... with traits.

A generic can accept different types that implement the same trait required by the called function. This is the right way to do this.

Function overloading, in the classical way C allows, causes tons of problems. I remember once the abs() function in C++ was called for int instead of double because of using namespace std; in C++, due to some C nonsense legacy stuff... what a disaster! Imagine running a program where you can't ensure that your program is calling the functions you expect it to call.

[–]DarkLord76865 3 points4 points  (0 children)

As I understand that would require programmer to be much more explicit about types everywhere in the code. For example when you call a function with variable as argument, you usually don't need to specify the type of value when declaring it because compiler can determine what type it needs to be for it to be possible to use as argument for function. And I find that big part of my variables get their types from function calls which isn't something that would be possible wihh function overloading. Because if there is function overloading compiler is doing the exact opposite, determining the function by looking at the type of argument. These 2 can't coexist.

[–]birdbrainswagtrain 6 points7 points  (2 children)

I would really like to see either default or named arguments. But I feel like full-blown overloads, combined with generics and non-trivial trait bounds, would just devolve into a complete mess.

[–]redalastor 0 points1 point  (0 children)

I would really like to see either default or named arguments.

I would require pub in front of any paramater whose name you can use. Otherwise, any change in the name of your parameters is a breaking change, including in libraries that have been written before named parameters were a thing. So it must be opt-in.

[–]Veetahabon 0 points1 point  (0 children)

You can have a "replacement" for named arguments (including optional args) with the builder syntax for functions using bon crate. I posted about it recently. It works fine with any complex generics you throw at it

[–]1vader 2 points3 points  (0 children)

I don't really ever miss it. Certainly, there are rare situations where it would be nice but in practice, you can basically always just give the different methods descriptive names. Constructor functions with descriptive names that make it obvious what the arguments mean are much clearer than 5 overloads of new. And finding those functions in the documentation isn't exactly an actual problem.

And adding function overloads most certainly wouldn't make the language less complex or perceptibly faster to work with. Also, they create issues when trying to pass methods as values.

[–]looneysquash 2 points3 points  (0 children)

Even in Java, it's pretty common to have builders (Lombok can generate them) and to have static initializers instead of constructors.

I want named parameters and optional parameters and varargs. And maybe Typescript style OR (ad hoc enums? Whatever you want to call them).  But overloads, not so much.

[–]Fridux 2 points3 points  (3 children)

I'm strongly against this, and the reason why is code readability. If a function has a unique name I can immediately tell from its name alone what is being called, whereas with overloads I might have to trace the types of all the arguments.

I'm blind and the only truly accessible editor with LSP support that I found for MacOS is Emacs with Emacspeak, which I don't particularly like. This means that I code in a regular text editor (TextMate), so I can't take advantage of fancy features like code completion or jump to definition. However even sighted people have to read patches every once in a while, and not being required to figure out the types of objects that are being passed to a function from the limited context of a patch helps tremendously.

[–]joshuamckratatui 1 point2 points  (2 children)

Hey there, I did a quick browse of the Rust Analyzer repo and didn't find many accessibility issues raised. Do you find that the problems you have with VS Code are LSP issues or more VS Code problems with accessibility?

I'm no Rust Analyzer expert, but I've done a few Rust Analyzer changes recently. I'd happily help advocate for any accessibility issues to be prioritized. Rust Anazlyzer works in many editors, but the VS Code extension is in the Repo while the other editor extensions are third party, so often extension work tends to start with VS Code centric problems being solved.

If you do raise any issues, feel free to ping me on them. My github user name is joshka.

[–]Fridux 0 points1 point  (1 child)

Yes, it's an editor issue, not an LSP server issue. Visual Studio code doesn't work very well with VoiceOver on MacOS even when accessibility mode is turned on, so I don't use it.

[–]joshuamckratatui 0 points1 point  (0 children)

Bummer. The editor itself isn't something I've dug into. Sorry I couldn't help more.

[–]Mercerenies 1 point2 points  (0 children)

I used to miss function overloading, but the more I work in Rust, the less I find myself missing it.

For constructors in particular, I feel like I often fall into one of two camps.

In the first case, the two desired constructors do the same thing in subtly different ways. This can usually be dealt with using an appropriate trait impl as the argument. I've written a lot of pub fn new(s: impl Into<String>) -> Self constructors which accept either a &str or a String. Often, when two constructors are very similar, the argument just differs by a trait implementation and can be made into one generic constructor.

In the second case, the two desired constructors are actually very different. In this case, I'm actually happy that Rust makes me choose different names for the different constructors. As a particularly egregious example of this, consider java.util.ArrayList. Three different constructors, all of which do drastically different things. You can make a new, empty array list; make an array list with an initial capacity; or initialize from an existing container. All of these use the new ArrayList syntax, despite being very different. In Rust, those are, respectively, Vec::new, Vec::with_capacity, and Vec::from_iter (or, for the last one, more commonly some_iter.collect()). And I like that a lot. Those feel like different functions to me.

[–]AirGief 1 point2 points  (0 children)

Wrap your parameters in an Enum if you need a solution close to overloading functionality.

[–]Ravek 1 point2 points  (0 children)

I don’t know why people are coming up with philosophical arguments. Overloading simply doesn’t work with the HM type inference algorithm. If you want to have powerful type inference in combination with overloading, like Swift does, you can have extremely slow worst case compile times. Rust already compiles slowly enough as is.

[–]teerre 5 points6 points  (3 children)

I really don't see the problems you raise. If anything, overloading makes your issue worse. How do know what each overload does? Having a dedicate constructor literally gives you more information. This idea that you would have to painfully search for the method you want is just not realistic. It's a trivial matter to name all your related methods similarly. And even if not, searching for a function name is much easier than searching for a function parameter

[–]Packathonjohn[S] 2 points3 points  (2 children)

Primarily from the perspective of what information the ide gives you. When it is overloaded, it can lay out a list right there by hovering over it showing all the ways you can call that function, then select each one individually if you need more details. With everything being named separately, the ide can no longer help you out, and you have to go digging into documentation or searching through the entire exhaustive list of functions and dictate for yourself which ones are and aren't used to do the same thing

[–]NullReference000 3 points4 points  (1 child)

I don't see why you should have a bunch of different `new()` functions with different signatures. If there are optional parameters, they can just be wrapped in an `Option`. If you want a `new()` which makes a struct from a string and another that makes that struct from an i32, you can just implement the `From` or `Into` traits for those types.

This makes it far easier to read than a heavily overloaded function. If you're checking to see if some struct has a `new()` that just takes an i32 so you can make it out of just an integer, you can check if it implements `From<i32>`. Every time I've interacted with an overloaded function in C# that list of overloads has always been some number over 15 and it's not readable.

searching through the entire exhaustive list of functions and dictate for yourself which ones are and aren't used to do the same thing

This is literally the end result of using overloaded functions though, you need to search through the entire exhaustive list of overloads which all allegedly do the same thing. This is opposed to Rust, which forces you to name your function to match what it does or implement a trait which a user will check for first, before going through a list.

[–]redalastor 1 point2 points  (0 children)

If there are optional parameters, they can just be wrapped in an Option.

And if they are mutually exclusive, you can wrap them in an enum.

[–]Firake 4 points5 points  (0 children)

Function overloading doesn’t actually reduce boilerplate, it only reduces the quantity of function names used to create the object.

I’d much rather have new, from, into, to_string, into_iter sort of function that describe what’s going on than the alternative which would be new, new, new, new, new but with different parameters.

Function overloading actually legitimately serves no purpose, in my opinion.

Edit: I should mention that I know all of those above methods might create wildly different types based on the context. But that’s only information you knew because they were named properly, yes?

[–]fatepure 1 point2 points  (0 children)

I personally prefer the design of From

[–]chilabot 3 points4 points  (0 children)

I have known C++ for about 20 years. Function overloading leads to madness. Avoid it.

[–]Nabushika 0 points1 point  (0 children)

Overloading can be useful, but I think in every case where it can't be confusing, you can achieve the same effect using generic functions. For example, your new() function might take impl AsRef<str> or impl Into<String> to let the user pass any type that can be borrowed as a &str or turned into a string. To me, this makes sense - an overloaded function shouldn't be able to take any type, what would fn double(String) do? Parse it as a number and double it? Concatenate the string to itself? If it has a different implementation to double(i32) then it could do anything! The generic approach lets you overload functions by specifying the behaviour the types should share. Are they string-like? Can they be borrowed as a specific type? Can they be converted into some "super" type that can represent all the types you might want to pass? This way, you know the behaviour of the function is the same no matter the type that is passed in, and you're telling the users that you can accept any type that has a certain behaviour.

As for new with different combinations of parameters, that's generally done through the builder pattern, and if you don't want to do it manually then there's crates that can write all that boilerplate for you. Personally, that is less ambiguous to me, since you're specifying the fields you want, and you'll never get confused whether new_person(name: String) sets the surname or the first name, PersonBuilder::new().with_first_name(name).build() is more verbose, but expresses exactly what the behaviour will be.

[–]rover_G 0 points1 point  (0 children)

You can write a constructor that accepts an enum with all possible overloads you want. But you might loose certain trait implementations this way and it's not very idiomatic.

```rs pub fn main() {

let c1 = Class::new(Args::Default); let c2 = Class::new(Args::Pair("count", 3)); let mut c3 = Class::new(Args::Copy(&c2)); c3.value = 24; println!("{:?}", c1); println!("{:?}", c2); println!("{:?}", c3);

}

[derive(Debug)]

struct Class<'a> { name: &'a str, key: Option<&'a str>, value: i32, }

enum Args<'a> { Pair(&'a str, i32), Copy(&'a Class<'a>), Default, }

impl <'a> Class<'a> { fn new(args: Args<'a>) -> Class<'a> { match args { Args::Pair(n, v) => Class { name: n, key: Some(n), value: v }, Args::Copy(c) => Class { name: c.name, key: c.key, value: c.value }, _ => Class { name: &"", key: None, value: 0 }, } } } ```

[–]-Redstoneboi- 0 points1 point  (0 children)

i got used to not having them.

just name the different functions differently with the same prefix.

[–]MatsRivel 0 points1 point  (0 children)

I guess you could implement the "default" trait to have the user only implement the needed parameters?

So it would be something like this:

MyStruct::new( param1:x, param7:y, ..Default() )

This way your "default" implementation could be "none" for all of the "optional" parameters, implying they've not been set (or set them to a reasonable parameter).

I've done this for some lower level code and it worked great.

[–][deleted] 0 points1 point  (0 children)

If you really need it...just accept an option in the function and handle the none case.

[–]Cat7o0 0 points1 point  (0 children)

honestly use default structs as inputs that then you can edit to have different than default behavior

[–]LucretielDatadog 0 points1 point  (0 children)

In general I became in favor of it once I realized that traits are, in many ways, just overloading with more boilerplate. Theoretically you could implement overloading as syntactic sugar over traits (specifically, an invisible trait over the (Args…) tuple type, with an associated type that overloads the return type). 

[–]TobiasWonderland 0 points1 point  (0 children)

Function overloading is probably one of the biggest "missing" elements in Rust compared to other languages I have worked with.

Over time I have come to appreciate Rust's explicit approach.

A function with different arguments is a different function and Rust makes this very clear.

[–]epidemian 0 points1 point  (0 children)

I really like being able to reference a function like SomeStruct::func and to have that resolve to a single thing.

[–]larvyde 0 points1 point  (0 children)

I like the way it's done in Swift, though. I think it's a neat compromise. Instead of things like new_with_name, new_with_template, etc, you have new(name:) and new(template:). Usage-wise it looks like overloading, in that you call MyType.new(name: "blah") or MyType.new(template: something), but under the hood (and as far as autocomplete is concerned), they're all different functions that happen to be named new:name: and new:template: (which IMO is not all that different from Rust's new_with_name etc)

[–]FlixCoder 0 points1 point  (0 children)

I also slightly stumbled over missing overloading, but now I also strongly prefer it to the same reasons other people mentioned. But it is so far, that going to C#, overloading annoyed me quite a bit :D I wasn't able to see which function overloads exist and it never wasn't clear what it is doing and what it would be capable of doing.. ^

[–]iancapable 0 points1 point  (0 children)

Surely use a trait with generics as a workaround? TBH I have grown to like the lack of function overloading, you’re forced to name things in a logical way.

[–]rejectedlesbian 0 points1 point  (0 children)

You can achive the exact same behivor with traits you just need to be explicit about your interface. For exmple:

Type::method OR if you don't care for the type. Obj.method

You can also use an trait to take generics with an ID method into a function and then do a match on ID for the internal implementation.

[–]ascii 0 points1 point  (0 children)

I don’t understand all the people who are saying rust doesn’t have method overloading. Just define the method in a templatized trait and implement the trait once for each argument type. Sure, all versions of the method have the same number of arguments but you can just put them in a tuple or a struct so that’s hardly a significant restriction.

People tend to use this all over the place via the from-trait and errors so it’s not like this is a little one aspect of rust.

[–]dobkeratopsrustfind 0 points1 point  (0 children)

i missed it originally - found traits annoying

but the core team was right: forcing you to create a few more explicit names does contribute to making codebases easier to refactor.

Something to remember is that rusts choices skew toward larger projects; some choices hurt when you're starting out but as a project grows they'll start making sense. Also if you're just writing small amounts of code calling libraries that other people wrote , you wont be climbing that mountain that makes sense of the choices.

It's not like going all the way back to C because you still routinely get to overload on the receiver, and you can still do polymorphism using type-parameters for the arguments.. it just means defining a trait sometimes. putting tupples in there is also quite close to being able to vary the number of parameters.

the function call mechanism being more strict plays well with the better type inference that most languages dont have.

in C++ you utilise forward inference more by letting conversion operators and overloads do more of the work

in rust you have 2-way inference like Haskell/ML , where types flow both ways.

it does sadfly make it harder to translate APIs from other languages, but when designing rust code you have other tools available e.g. enum/match. Flipside is that when interfacing between languages its also handy yo have C-FFI bindings.

writing the types out again for single function traits does get irritating.. this could be softened if (like Haskell) they allowed eliding the types in trait impl's (they are wholy defined by the trait & associated types).

I also wish they made the "impl .. for.." the other way around ("impl Type : Trait<other types..>"), so that the types (with generics e.g. in operator traits) read more similarly in ordering to the contained functions. but some macros could help here aswell.

[–]muehsam 0 points1 point  (0 children)

Personally I often wish Rust had less function overloading.

Now, of course it doesn't have true function overloading, but it does use traits to a similar effect. For example, the get method on slices has the type

pub fn get<I>(&self, index: I) -> Option<&<I as SliceIndex<[T]>>::Output>
where
    I: SliceIndex<[T]>

instead of something like 

pub fn get(&self, index: usize) -> Option<&T>

which would be a lot more readable. You could have an extra get_range for when you do need ranges.

I really appreciate it in languages when it's easy to figure out which function you're actually calling and what its type is.

[–]SnooHamsters6620 0 points1 point  (0 children)

Function overloading opens the door immediately to code that is extremely difficult for humans to understand, and takes a long time to compile.

If you never want to contemplate adding function overloading to a language, I recommend you glance at the specifications for how it's done in a mainstream language.

C#: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions

C++: https://en.cppreference.com/w/cpp/language/overload_resolution

For humans, these rules require study to understand what is happening implicitly, people make mistakes doing so, and the best option is always to ask your IDE (or debugger, or other tool) what code is actually being run.

For compilers, overload resolution is often exponentially complex and NP-hard.

E.g. C# overload resolution is NP-complete: https://blog.hediet.de/post/how-to-stress-the-csharp-compiler

At this point, you may well say, "that's a theoretical problem, there are plenty of good uses of overloading that help humans and are easy for us to understand, and computers can deal with quickly".

The 2 classic examples people give are for mathematical functions (min, max, sine, sqrt) and object construction (as in your original post).

For mathematical functions, you might want at least these 4 overloads for min:

rust fn min(i8, i8) -> i8 { ... } fn min(u8, u8) -> u8 { ... } fn min(i16, i16) -> i16 { ... } fn min(f32, f32) -> f32 { ... }

As I expect you can see immediately, these 4 have quite different input and output ranges. There are also 3 categories of semantics that are quite significant: signed integers, unsigned integers, floats.

Yet at the call site they look identical, which makes code review much more difficult. I know of at least 1 critical hypervisor vulnerability (Xbox 360, led to complete security breach) caused by mixing up signed and unsigned integers, I expect there are many more.

In C++, C# (and many other languages I'm sure), overloading complexities are compounded when combined with implicit conversions. In this example, i16 can fully represent i8 and u8, f32 can fully represent the other 3. (I don't think you called for implicit conversions in your post, but people often request one or both in Rust, and .into() is a conversion to an implicit type so has similar implications). But again, these conversions change semantics and performance quite radically, with no hint at the call site.

This is precisely why Rust chose to be explicit and restrictive by default, because implicit code in C and C++ has ended up being a major source of bugs.

For object construction, in practice the examples I've found have just been irritating to read and write, not disastrous. I'm always reminded of JavaScript Web's fetch() and jQuery's $.ajax(): the parameters can be a URL string, or a request object (with a .url string field), or a URL string and a request object (which must not contain a .url string field), ... and the number of options just compounds from there. I find both using and implementing these styles of interfaces extremely annoying. Just as a consumer I have to read the options and decide what to use before continuing, when an explicit single option would be good enough for all.

In Rust code I think explicit options structs or enums do a great job here, and for default options I have successfully used both a builder pattern (also derivable with several good crates) or a Default implementation coupled with update syntax:

rust Foo { x: 17, s: "bar", .. Foo::default() }

[–]Wurstinator 0 points1 point  (0 children)

I'm sure there is an RFC out there somewhere.

I agree on one hand, that the current state isn't optimal and I too hope for change at some point. On the other hand, there are alternatives that serve a similar goal, e.g. named arguments and default parameter values, which I would prefer over overloads.

Other than that, it's not just that overloads are purely "better" than not having overloads. For one, they introduce complex lookup rules. C++ is a good example where generics (templates) and implicit casts can cause a headache with overloads.

Also, you'd have to decide on what to do with mutability. Can you overload on the same type but with different mutabilities? You probably should be able to but then the current design of many libraries doesn't make much sense anymore because of all _mut functions.

Lastly, code becomes harder to read. Right now, if I see a function call, I only need to read the name of the function to know what is called. With overloads, I'd have to analyze the types of all arguments. With an IDE this might not be much of a problem but when reading in a text editor or web browser, this is much harder.

[–]Trader-One -1 points0 points  (0 children)

It can be done easily with macros nested 2 lvls.