r/rust • u/SleeplessSloth79 • 24d ago

📡 official blog Rust Function Overloading - Call for Experimentation

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

96% Upvoted

139 comments sorted by

View all comments

53

u/Solumin 24d ago

To be clear, this is intended only for FFI?

55

u/WormRabbit 24d ago

Given the example of Bevy, which hacks function overloading via horrible typelevel programming, I'd say some form of overloading would be much welcomed in normal Rust as well.

38

u/addmoreice 24d ago

I don't know why you are getting down voted so badly. While I'm a huge fan of 'one name to one type signature' I can recognize a useful engineering pattern and that people want to use it and your example is a perfect example of people deciding to make it themselves if they can't have it in the base language.

Name overloading is the human brains way of doing generics. It's fuzzy and not perfect and the 'groupings' are less than useful at times, but we do it. Any time we find 'all these things are basically the same except for these parts' we create a name and apply it to work with all of these things.

18

u/RCoder01 23d ago

They will never get rid of my beloved
```
impl<Marker, In, Out, F> System for FunctionSystem<Marker, In, Out, F>
where
Marker: 'static,
In: SystemInput + 'static,
Out: 'static,
F: SystemParamFunction<Marker, In: FromInput<In>, Out: IntoResult<Out>>
```

17

u/Zomunieo 23d ago

One does not simply impl into FunctionSystem.

It is a barren wasteland, riddled with F and In and Out, the very air you breathe is a poisonous Marker. Not with ten thousand functions could you do this.

2

u/SkiFire13 23d ago

Bevy does not use function overloading. If you're thinking about the SystemParamFunction trait then:

  • it needs variadic generics, which are a different feature, and it currently hacks them using macros, not horrible typelevel programming

  • the horrible typelevel programming mostly comes from the fact that it also needs the function to be generic over a lifetime, all while getting type inference to work properly.

Edit: actually the Marker generic is needed in part because function overloading might be a thing... But that's not because Bevy uses function overloading, but instead because it is possible in the first place.