value class support and typeclass paramaterisation

[hughsimpson]

Two things have been bugging me about magnolia in scala 3:

• the inability to paramaterise typeclass construction with an auxiliary typeclass
• lack of support for value classes

This goes some of the way towards addressing those issues. Since it changes derivation signatures I decided to implement this as 'more capable' variants of the derivation traits, rather than breaking all the bin compat.

Value class support is implemented by providing an appropriate mapping on the derivation but is a bit clunky as it stands, and the macros don't support: non-product (i.e. non-case class) wrappers, private constructors for 'extraction' typeclass, or private accessors for 'wrapping' typeclasses; although I think the last two are achievable with judicious modification of the macro, and the first might be, although I'm not sure how, and it would probably break the signatures here...

See geirolz/cats-xml#251 for motivation

Obviously I'm more than happy to amend aspects of this according to feedback, so arguably I should've opened this as a draft WIP, but there aren't any further changes I'd particularly planned to make initially (other than naming, I see now. Left in 'Serde' in some names, but that aside...). Feedback welcome

[hughsimpson]

This is fiddly to implement, but still better than writing the macros yourself... I imagine it can be a whole lot nicer than this

[hughsimpson]

The structure here is probably a little wonky... Thinking about it, the value class support should probably be some kind of optional mix-in...

[hughsimpson]

Am I the only one who misses these capabilities, or is there an approach for them that I've missed, or...? I'll push up some more strenuous tests as soon as I have the time, but I'd like to get confirmation that I'm not just completely mad and that this is a reasonable direction to take

Edit: maybe I shouldn't be trying to combine this into one pr? I dunno. Feedback very welcome.

[adamw]

Quite the contrary, there are often questions about value classes. However, the state of this feature isn't that rosy: the related issues are #296 and #294. At some point we started an effort to release magnolia-scala3 v2, with value classes support: #443, but unfortunately it stalled, and even more unfortunately, the v1 & v2 branches diverged. So I guess it's still our plan to re-create v2 or port the changes to the existing v2, but I don't really know when ;)

As for your PR, as I understand it introduces a parallel derivation mechanism? I guess it would be better than just to work on a v2 version. Also, I think using Mirrors can have poor performance, so going macro-only might yield better results.

Finally, you write:

the inability to paramaterise typeclass construction with an auxiliary typeclass

can you share an example of what the problem here is?

[hughsimpson]

Thanks for the feedback. Tbh I opened this pr too early and there were unresolved issues even to my mind once I read it through - will try to get back to it soon, but will convert to a draft in the meantime.

The specific use-case I had in mind re paramaterisation was for cats-xml, where the pattern is to instantiate an implicit declaring certain properties - such as field foo should be an annotation, field bar should be a node, field baz should be text content - and use that in the derivation to generate the appropriate serde. Although I've run into a similar issue once where the usage wsa intended to specify the discriminator for some JSON serdes being derived for spray-json, and I pretty much couldn't do it without the derive implementation knowing about the traits in advance and this would've helped there. I'll try to write some tests to show this sort of use case

I'll take a look at V2 that's probably a better direction.

[adamw]

Ah yes, having (failing) tests would be great.

As for V2, I'm also hoping to include some ideas by @MateuszKubuszok (see https://www.youtube.com/watch?v=h9NdXLTZkGk) to make Magnolia not only feature-full, but also fast :)