Looking at Rust's preliminary fn trait model (basically the function call operator) and I don't get one thing:

Why is the argument tuple a generic type parameter and not an associated type? It would've been so easy to ensure consistency in the position that Rust doesn't have overloads. A trait can be implemented for any number of generic type parameter values, but an implementation may only have a single type for each association.

To make things worse, the return type is an associated type, even though the presence of Hindley-Milner type inference clearly indicates that there isn't intended to be any difference between argument and return types in terms of dispatch.

Like I know that forward inference feels more intuitive, but with the whole expression-driven declarative thing Rust has, I'd say backwards inference is actually vastly more common. We're past the point where you could just point to C++ for the right choice. If it hopes to carve out a niche, Rust should lean into its strengths.

To me, there are two sensible approaches here:

1. Fn<> can have multiple implementations for the same concrete type like most STL traits, arg and return types are template parameters, accept the fact that people will make overloads with this. Kinda conflicts with the spirit of the language IMO.

2. Fn has no template parameters and therefore only one implementation for a concrete type like the intrinsic function call operation, arg and return types are associated types, double down on the absence of overloads outside explicitly named trait operations.