-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mirror-less Scala 3 #321
Mirror-less Scala 3 #321
Conversation
Thanks! I think it might turn out recursive types work as-is, but maybe we could support value classes and non-trivial sealed trait hierarchies, for which mirrors are currently not derived. |
FYI the base branch is now |
d9ce9d3
to
03abe6b
Compare
44ff47a
to
235dfd8
Compare
235dfd8
to
9fcf075
Compare
Ok, so this branch should now pass at least as many tests as the @adamw will you be able to find some time to take a look at the changes and give some feedback? It would be great to test it on some real-world libraries that use |
So one thing that breaks is calling magnolia from another macro: Even in a simple case: case class Test1(f1: Int)
implicitly[Schema[Test1]]
val codec = implicitly[MultipartCodec[Test1]].codec the |
But is it something that we actually care about? if |
Not sure I understand - |
This is how to reproduce, inside // test1.scala
package magnolia1.tests
import magnolia1.examples._
case class Data(value: String)
object Test1 {
summon[Show[String, Data]]
Test2.summonShow[Data]
}
// test2.scala
package magnolia1.tests
import magnolia1.examples._
import scala.quoted.*
object Test2 {
inline def summonShow[T]: Show[String, T] = ${ summonShowImpl[T] }
def summonShowImpl[T: Type](using Quotes): Expr[Show[String, T]] = {
import quotes.reflect.*
Expr.summon[Show[String, T]].getOrElse(report.throwError(s"Cannot find a Show for: ${Type.show[T]}."))
}
} The direct |
there is a problem with current impl which i hope can be addressed as well with the rewrite |
actually the problem seems to be easy to fix with old implementation, i submitted a pr |
@OlegYch You obviously can flatten the hierarchy in this rewrite too, but I'm not sure if that's what we want. Don't we lose some information, when we flatten the type hierarchy like that? I'm pretty sure that there's a way to implement |
@KacperFKorban i thought so too, but it appears to be no way to make |
Draft of mirror-less implementation for Scala 3. Probably most of the code can be simplified a lot. But should be a good start for testing if recursive types can be handled properly this way.
Related to #310