Overloadable functions with tuples - why can't compiler do that?

Function overloading has a million problems but this ain't one of them. That's much more about Rust not using argument labels at call sites. Esp. because, even if I know that there's only one overload foo(bool, bool, bool, string), I still have no idea how to call the darn thing. After touching Swift, I can't help but see this omission as an ancient relic of the past.

Shameless Plug: overlodable crate I made which is nightly only but provides both member function overloading and standalone function overloading.

I'm still against function overloading and I believe that using a builder pattern is much more elegant and idiomatic.

3 Likes

So you are [ab]using the one place in the language where that “dirty and controversial” conversion that we are talking about is already implemented today?

Clever. I guess if I would be forced to use nightly for some reason I would think about using it (or just reimplemnting it, it's not that hard to do).

But let me remind about rule zero:

  • For the foreseeable future, C++ is the reigning monarch in our codebase, and any use of Rust will need to fit in with C++ — not the other way around

Google tells you about that rule explicitly (and in not uncertain terms, it's quite literally: you have to deal with that, end of story) and about 90% of potential Rust users (if not 99% of potential users) are in the same situation: unless Rust can prove itself in a small, pilot project where zero requirements are placed on developers who are continuing to use C++ (JavaScript, C#, Ruby, Java, Python, whatever) it would never be allowed int the codebase and thus may never be used in larger, non-pilot projects.

At some point Rust will have to do the deal with that devil, the question is about details of the deal not about the need to do it.

I'm still against function overloading and I believe that using a builder pattern is much more elegant and idiomatic.

Sometimes. I'm not sure I would use builder pattern 100% of time even when I'm dealing purely with Rust. But for the foreseable future Rust wouldn't be in the diving seat. It have to deal with lots of code written for other languages and a lot APIs designed for other languages — and most languages out there support function overloading in one form or another. C, C++, C#, Java, JavaScript, PHP — all the most popular languages have it (yes, even C and JavaScript! C have variadics and JavaScript have optional arguments).

Thus it's not really a question of “would we support that feature” but “how would we support it”. The current most popular approach which produces that init_mouse_event_with_can_bubble_arg_and_…_and_related_target_arg is certainly suboptimal.

First of all: the foremost goal of Rust was never, and will probably never be, to please a specific company. If Google don't want to use Rust because they feel it doesn't "fit in with C++" (what does that even mean?), then they are free not to, and the Rust team and wider ecosystem will still continue working without them just fine.

Secondly, what does this have to do with overloading? Are you suggesting that Rust should try to be as similar to other languages as possible, and thus have overloading, because C++ has overloading too? That's not a requirement (or even a desirable property) for FFI interop.

I.e., dynamic typing – which you can pretty much replicate using &[&dyn Trait]. I don't see how you would consider C's primitive notion of variadic arguments more powerful than what you can also do in Rust. Yeah, it doesn't have the same syntax, but that's hardly what matters in terms of expressive power.

That's an abysmal function name, and it's definitely not the norm in any decent language. Certainly it is not "the most popular" approach in Rust. Please don't misrepresent the community. If you search a bit around on URLO, you can find a lot of advice to the contrary, usually amounting to a recommendation to implement a struct with named fields and sensible Defaults.

If you search a bit around on URLO, you can find a lot of advice to the contrary, usually amounting to a recommendation to implement a struct with named fields and sensible Default s.

And if you search around on crates.io then you realize that foreign ABIs are usually implemented that way. So it becomes case of “do as I say, not as I do” — and in cases like that I consider crates.io and not URLO the measure of popularity. Sorry.

That's an abysmal function name, and it's definitely not the norm in any decent language.

Yet that's what crate owned, as crates.io claim, by Alex Crichton, Nick Fitzgerald and others contain.

If these guys are considered “Rust novices who don't have enough experience” then can you tell me, please, who do you consider Rust experts who's example we should follow?

I.e., dynamic typing – which you can pretty much replicate using &[&dyn Trait] .

I'm eagerly waiting for your fix for the “abysmal function name” in official crate recommended to be used by developers who want to use Rust with wasm. If what you say is true this should be easy fix.

Are you suggesting that Rust should try to be as similar to other languages as possible, and thus have overloading, because C++ has overloading too?

No. I'm just saying that while Rust should not be duplicating every feature that C++ have and every mistake that C++ have (that would be silly: if I wanted to use C++ I would have used C++, right?) but when something simple and easily fixable makes interaction hard… for no good reason… that's shoddy work. And must be fixed.

First of all: the foremost goal of Rust was never, and will probably never be, to please a specific company.

Specific company? No. All companies taken together? Yes. async/await were added to language on a fasttrack because otherwise lots of companies weren't interested in Rust.

Lack of proper function overloading is not major PITA, more like some minor irritant which makes use of Rust needlessly more painful, thus it may wait, I guess.

But deficiency of interaction with C++ (and to lesser degree other languages) would be addressed, sooner or later — because that's not something Google needs, but something most companies which may actually support Rust development need. Including all Rust Foundation members.

If Google don't want to use Rust because they feel it doesn't "fit in with C++" (what does that even mean?)

That one is easy. C++ libraries should be accessible from Rust automatically without any manual work — and in easy-to-use way. Certain features would, probably, not supported well (e.g. self-referential moveable C++ types should probably stop being moveable when accessed from Rust and would be used using Pin, e.g).

And this would would be finished one way, or another (why do you think LLVM got cross-language inlining two years ago?), the only question is: would that be still called Rust or would Rust be abandoned and all Rust Foundation members would switch to some kind of fork.

I'm pretty sure Rust would survive even if quite a few feather of some venerable Rust developers would be ruffled. You thought Steve Klabnik tantrum was bad?… just wait till Rust Foundation would start pushing for the delivery of certain features in predictable fashion, not after years of bikeshedding. Sadly function overloading probably wouldn't be among these (it's less of real issue and more if an irritant, since acceptable even if ugly solutions exist) and we would have that init_mouse_event_with_can_bubble_arg_and_…_and_related_target_arg crazyness for a long time yet.

This thread has gotten quite hostile and never was really productive. Not supporting overloads was an intentional design decision, I would encourage researching why (I'm not familiar with all of the specifics).

VorfeedCanal, if you want to get an understanding of why, I would encourage searching on IRLO, and if there is no existing thread, asking in an exploratory fashion, not accusatory. "Why was this decision made? I don't quite understand x, can you elaborate?" etc

13 Likes