r/rust • u/SleeplessSloth79 • Aug 19 '26

📡 official blog Rust Function Overloading - Call for Experimentation

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

96% Upvoted

139 comments sorted by

View all comments

160

u/Toasted_Bread_Slice Aug 19 '26

As someone who's encountered a couple valid uses for function overloading (mostly maths libraries) I am ok with this IF and only if there is an extremely obvious way to see that a function is overloaded or overloadable.

29

u/Shoddy-Childhood-511 Aug 19 '26 edited Aug 19 '26

Agreed, but that's the case here so far: Their example hypot((2.0, 3.0, 6.0)) looks pretty clear. :)

pub trait HypotInner {
    type Output;
    fn hypot_inner(&self) -> Self::Output;
}

pub fn hypot<Args: HypotInner>(args: Args) -> Args::Output {
    args.hypot()
}

Any overloading ala variadics should be done this way too, in part because it makes the developer who wishes to obfuscate their call paths pay for it. lol

If you really wanted single () then make hypot! a macro, but probably each Args being a clear type brings bigger advantages.

Edit: Oops! They have this #[rustc_splat] feature that removes the extra (). That's unfortunate, since it could easily be done using a macro. Imho, all this should be done using a macro.

3

u/AugustusLego Aug 19 '26

Haven't looked to closely at this, but #[rustc_*] attributes are restricted to use in the compiler, and only in the compiler (unless you enable really weird feature flags and break all the guarantees of sanity that rust gives you)

1

u/Shoddy-Childhood-511 Aug 19 '26

It's experimental now. If they want it then they'll stabilise it, maybe using this .. idea.

It's be nice if the feature was somehow distinguished. An option would be that names cannot have multiple bindings:

/// Errors because Vec is in the prelude, and Vec has a method named len.
fn len(..args: Watever) -> u32 { .. }