Why use generics instead of associated types in Handler definition?

[chernoivanenkoofficial]

Summary

I am currently trying to build service contract framework and integrate it with axum as one of server-sides. The problem I encountered is that to enforce a subset of endpoint arguments I need to check the arguments, that handler accepts. And, as axum uses generics in trait for handler definitions (and mixes in a marker type for FromRequest monomorphisation on top of the things that make this task difficult), trait bounds for all the needed checks get either bloated or straight up impossible to construct.

Hence, I have the next question: why use generics instead of associated types in Handler definition (and may be some other ones as well)? There is no use case on my mind (and axum docs) where a single type could logically or possibly implement Handler trait more than once. So why parametrize implementations around the arguments, instead of setting the arguments as an associated type, like the following:

pub trait Handler<S>
// constraints ...
{
	type FromRequestMarker; // Either ViaParts or ViaRequest
	type Args;

	/// ...etc
}

axum version

0.8.4

[jplatte]

Both of these things are not actually used by the trait, they exist to work around coherence. Since a type can (from the type system's perspective) implement both Fn(X) and Fn(Y) (the arguments are a generic type for the Fn traits as well, not an associated type), we need the extra generics so all the impls we have for Handler don't conflict with each other.