Scala 3 extractors and Scala 2 binary compatibility #21563
-
While examining a library-specific binary compatibility issue - which can be seen with its error messages here: #21560 - I found that it was caused by a more general phenomenon, namely that I created a demo project to illustrate this: https://github.com/kincsescsaba/scala-compiler-crash-cc-unapply/tree/master If I run the demo, I get this output:
Looks like a Scala 2 case class If you check the library-specific issue cited above, you can see that the runtime looked for a Scala 3 specific Even though Scala 2 and 3 should be binary compatible, looks like this issue was not handled. I'd like to understand if the different return type is a bug or a feature, is this issue common and is there a workaround in plan? Like generating/accepting both |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
So Scala 2 is binary compatible with Scala 3, in that the Scala 3 compiler can understand and compile code against a Scala 2 library. But Scala 3 decided to change the return type of case class unapplies, and that is an improvement in Scala 3. But it's still able to consider Scala 2's unapplies as extractors, and case class extractors at that (i.e. irrefutable). If you use reflection, you'll see the difference - but that doesn't make them "incompatible". |
Beta Was this translation helpful? Give feedback.
-
This question was asked in another forum, but I can't find it. What is the link? |
Beta Was this translation helpful? Give feedback.
So Scala 2 is binary compatible with Scala 3, in that the Scala 3 compiler can understand and compile code against a Scala 2 library. But Scala 3 decided to change the return type of case class unapplies, and that is an improvement in Scala 3. But it's still able to consider Scala 2's unapplies as extractors, and case class extractors at that (i.e. irrefutable). If you use reflection, you'll see the difference - but that doesn't make them "incompatible".