Description
We currently support function specialization but not tuple specialization. It would be good to support that as well, so that we are on parity with Scala 2 programs that use the features of the standard library.
Detailed description of the Semester Project
Problem
As an example, if you compile the following:
class Foo {
val x: (Int, Int) = (1, 1)
val y: Int = x._1
}then decompile it using cfr, you'll see boxing/unboxing between int and Integer in Scala 3 but not in Scala 2, because Scala 2 uses the specialized class Tuple2$mcII$sp generated by the Scala 2 compiler from the @specialized annotaiton on https://github.com/scala/scala/blob/7c7890b0ba5fb5ffa896bfedcab04e1bacc12ae7/src/library/scala/Tuple2.scala#L24 . Because Scala 3 reuses the Scala 2 standard library (the scala-library jar) we don't need to support generating the specialized classes ourselves and can just assume they exist.
Note that we already have similar logic for dealing with function specialization which is more complex since users can define their own subclass of FunctionN whereas the TupleN classes are final: https://github.com/lampepfl/dotty/blob/master/compiler/src/dotty/tools/dotc/transform/SpecializeApplyMethods.scala / https://github.com/lampepfl/dotty/blob/master/compiler/src/dotty/tools/dotc/transform/SpecializeFunctions.scala
Solution
The solution is to develop a new miniphase in the compiler that will specialize tuples the same way SpecializeFunctions does it for functions. We can reuse the specialized tuple classes from the Scala 2 standard library as described above.
Roadmap
- Play with Scala 2 specialized tuple classes in a standalone Scala project to get an idea of how they work.
- In the standalone project, develop a prototype with the low-level code the tuples must compile to.
- In the compiler, develop a new miniphase similar to SpecializeFunctions that will generate the code you previously implemented in a standalone project.