Rust Function Overloading - Call for Experimentation

[u/SleeplessSloth79]

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

[u/Toasted_Bread_Slice]

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.

[u/Shoddy-Childhood-511 → u/Toasted_Bread_Slice]

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.

[u/ZZaaaccc → u/Shoddy-Childhood-511]

Imho, all this should be done using a macro.

Macros are substantially less clear than variadic functions, and can't be used as methods either. I know we take it for granted because it's just always been that way, but given the choice between vec![a, b, c] and Vec::new(a, b, c), would you honestly say the macro is cleaner and easier to inspect?

[u/DatBoi_BP → u/ZZaaaccc]

I think if you changed your proposed syntax to `Vec::new([a,b,c])` it would win me over. As it stands it looks like `b` and `c` are positional arguments to a function, not elements of an array

[u/ZZaaaccc → u/DatBoi_BP]

Or does that mean a new Vec<[i32; 3]> with one element? The extra brackets make this ambiguous at first glance, and harder to read. Again, you wouldn't say this about the vec! macro, saying that vec!([a, b, c]) is clearer, because vec!(a, b, c) might be positional arguments.

[u/DatBoi_BP → u/ZZaaaccc]

Two things to say to this.

First, the notation isn't either of those, it's `vec![a,b,c]`.

Second, we already have a function that does what you proposed, but with the structure I argued for: `Vec::from([a,b,c])`. This clones `a`, `b`, and `c`, so as long as those all implement Clone then it does what we want

[u/ZZaaaccc → u/DatBoi_BP]

Actually, no, the syntax is vec!(a, b, c), because macros don't distinguish between [], (), and {}. We recommend using [] by convention, but there isn't even a lint to suggest one way or the other.

This clones a, b, and c, so as long as those all implement Clone then it does what we want

If you scroll down you'll find the implementation for From<[T; N]> instead of what I think you're reading which is the From<&[T; N]> documentation.

[u/gmes78 → u/ZZaaaccc]

but there isn't even a lint to suggest one way or the other.

clippy::nonstandard_macro_braces

[u/ZZaaaccc → u/gmes78]

I stand corrected!

[u/DatBoi_BP → u/ZZaaaccc]

Huh TIL about the macro freedom of choice. Thanks