Adam Warski

@ghostbuster91 what if you add an explicit type parameter to `derived`? e.g. `Show.derived[[X] =>> Show[String, X]]]`?

Adding `scalacOptions ++= Seq("-Xmax-inlines", "50")` solves the problem, however I'll keep this open as the case classes involved aren't that complicated so this can come up pretty often. Maybe rewriting...

Currently derivations often fail with messages like: ``` cannot reduce summonFrom with (...) ``` TODO: example

Promised example, using the classes from tests: ```scala case class Param(a: String, b: String) case class TestEntry(param: Param) ``` When you do: ```scala SemiPrint.derived[TestEntry].print(TestEntry(Param("a", "b"))) ``` you get: ```scala [error]...

I don't think there has been any developments around this, but we're open to discussion and contributions :) I guess the main question is what would happen when calling `caseClass.param.typeclass`...

Ok, well I don't see a reason not to support such transient fields. We just have to come up with a good name (`@deriveTransient`?) and implement :)

But the default would have to be per-typeclass, so I don't think it applies here. A downside of an annotation is that it requires modifying the case class (derivation source),...

@joroKr21 I like that :) Even better, maybe we could simply parametrise the derivation macro with a code that would decide, if a field should be ignored or not (and...

I was thinking about Scala 3. I think the design is more or less sealed and "done" for Scala 2.

It does seem these are two separate issues/tasks really :) If anybody is up to implementing it, I think we can go with the config as @joroKr21 suggested for Scala2....