Is it possible to use semi-auto with recursive structures?

[jducoeur]

(Phrasing this as a question, because I don't know if this is already possible, or whether this is an enhancement suggestion.)

Given this trivial code:

sealed trait T

case class Ts(ts: List[T]) extends T

I can use full auto to derive a Diff, but it's extremely slow. I would like to be able to use semi-auto, to bring down compilation time, like this:

implicit val tdiff = Diff.derived[T]

but that fails with complaints from Magnolia, and I can't for the life of me find a variation that gets past them. I've tried spelling out various combinations of explicit derived calls, using low-priority traits and all, but each one trips up on the Magnolia macros.

(My actual use case is much, much more complex -- nested sealed traits with various recursive sub-classes -- but this seems to be the nub of the issue: I can't even figure out how to get past the starting line here.)

I really like Diffx, and would like to use it, but the compilation time for auto-derivation is problematic enough (presumably because of the complexity of the structure) that it may turn into a blocker for us. So I'm hoping that there's a way to make semi-auto work for recursive structures.

[ghostbuster91]

Hi, As far as I remember this should just work.

Below seems to work for me (for all supported scala versions):

sealed trait T

object T {
  implicit val tdiff: Diff[T] = Diff.derived[T]
}

case class Ts(ts: List[T]) extends T

It seems that specifying variable type is sufficient to make magnolia macro happy. Let me know if this also helps in your case.

btw. I am going to put diffx into a maintenance mode soon (I should've done this long time ago). I don't have time and energy to maintain this project anymore, and there is quite a good alternative for it - https://github.com/jatcwang/difflicious

[jducoeur]

It seems that specifying variable type is sufficient to make magnolia macro happy. Let me know if this also helps in your case.

Huh -- I thought I had tried that, but maybe not. I'll give that a try -- thanks!

btw. I am going to put diffx into a maintenance mode soon (I should've done this long time ago). I don't have time and energy to maintain this project anymore, and there is quite a good alternative for it - https://github.com/jatcwang/difflicious

Ahhh -- okay, that's good to know now. I'm in the process of spinning up a major new test harness at work, but am only a little ways into using Diffx (I just hit a particularly complex comparison problem yesterday), so it sounds like I should try to pivot to difficilious. Thanks for the heads-up!

[adamw]

@ghostbuster91 maybe I'll archive the project then? would be great to see it going, but resources are limited

[jducoeur]

@adamw If you do so, please leave a prominent forwarding pointer at the docs location (and in the README) to diffilicious -- it's enormously helpful for us users to have the recommendation for an alternative.

[ghostbuster91]

@adamw I decided to wait with it till the end of the year to give users time to migrate and to give us a chance to merge & release any bugfixes that might be contributed.

@jducoeur I already added a link to difflicious to the readme, but good point with adding it also to the documentation :+1:

[adamw]

@ghostbuster91 makes sense, thanks :)