It seems there’s a trend of having many (3+) type parameters in user facing APIs of popular libraries, e.g.:
- Tapir,
Endpoint[A, I, E, O, R]
- Sttp,
RequestT[U, T, R]
, `` - Zio,
ZIO[R, E, A]
When using libraries like the above, it would be nice to support named type parameters at call site:
// definition site
trait MyEndpoint[Security, Input, Error, Output, Requirements]
now, if we had named type parameters, we could write something like this:
// call site, somewhere else in a downstream library/app
val securedEndpoint: MyEndpoint[Security = BasicAuth, Input = String, Error = String, Output = BusinessObject, Requirements = NoRequirements] = ???
compare that to the unnamed parameters:
val securedEndpoint: MyEndpoint[BasicAuth, String, String, BusinessObject, NoRequirements] = ???
What are String
, String
, and BusinessObject
? It’s no longer clear.
I believe the tendency to use single-letter names for type parameters sometimes comes from the fact that they are basically not user-facing – at least they have no bearing on the names in the user code. To me, it feels like a missing piece in terms of documenting your API, especially when the number of parameters increase. Thoughts?