Jon Pretty

a little gem lurking in the magnolia docs: "however, there is the flexibility to provide additional type parameters or additional implicit parameters to the definition". Adding additional implicits lets you use other typeclasses in the derivation. @propensive

Yes, maybe I should make that clearer! The concept is that the Magnolia macro will just glue together the appropriate method calls, but doesn't require an exact signature (in the OO sense) for each implementation, as long as they have the right "shape" to be called.

How hard would it be to allow driving tc A for case class where each member has an instance of tc B? I had to fallback to shapeless for this ;(

If I understand correctly, that's exactly the use case that the text @davidtx pointed to should help with. Just put a context bound on the type parameter to your `combine` and `dispatch` implementations.

If you want, you can even have a different Magnolia generic derivation provide the implementation for the second typeclass.

In my use case I would have to have def combine[T](caseClass: CaseClass[InputTC, T]): OutputTC[T] so CaseClass captures instances of one TC and produces an instance of other TC. Maybe this works right now, will have to check.