Apologies for the naive question, but why is the "partially applied" pattern used in this scenario? I was under the impression that it helps with type inference if the method is supposed to walk, talk and quack as though it had multiple parameter lists.

Hi, Adam! 😄 Ask all the questions you have!

Unfortunately, one cannot partially apply type parameters. We need to use this pattern if we want to be able to call this method as such:

ZIO.serviceWith[Foo](_.foo(int))

If it didn't use this awkward PartiallyApplied class trick, we'd have to specify the error and return types:

ZIO.serviceWith[Foo, Nothing, Int](_.foo(int))

So it's just a slight QOL improvement.

Gotcha. In an alternative universe, would an alternative Scala allow something like this?

def serviceWith[Service][E, A](f: Service => ZIO[Has[Service], E, A])

If so, has such syntax been proposed with the keepers of Scala?

Gotcha. In an alternative universe, would an alternative Scala allow something like this?

def serviceWith[Service][E, A](f: Service => ZIO[Has[Service], E, A])

If so, has such syntax been proposed with the keepers of Scala?

In scala3 you have named type arguments

If I'm not mistaken, it should allow you to do something like:

ZIO.serviceWith[Service = Foo](_.foo(int))

@ivanpagano That's amazing! I had no idea.