Named type parameters

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?

3 Likes

After writing this, I realize that it may already be possible in Scala 3?
https://dotty.epfl.ch/docs/reference/experimental/named-typeargs.html#

it seems like this is not yet possible

1 Like

Yes, the feature request has a long history. I think Dotty experiments are only enabled in nightly builds, or if you clone the project, ./bin/scalac will build itself and run.

The feature which has not yet been proposed is type parameter acronyms.

Instead of MyEndpoint[Security, Input, Error, Output, Requirements], write MyEndpoint[SIEOR].

1 Like