How to support Mirrors for Generic Tuples arity +22

Since #15250 we can now synthesize mirrors for generic tuple types if they have arity <= 22, we can do this because we pretend the mirror was for one of the equivalent scala.Tuple<N> classes.

We can’t do that for TupleXXL however as it has no accessor methods, and supporting them by creating fake accessor names would break the assumption that MirroredElemLabels corresponds to field accessors. Look at the example below:

Compiler version

3.2.0-RC1-bin-20220606-cec9aa3-NIGHTLY

Minimized example

case class Row(
  a1: Int, a2: Int, a3: Int, a4: Int, a5: Int, a6: Int, a7: Int, a8: Int, a9: Int, a10: Int,
  a11: Int, a12: Int, a13: Int, a14: Int, a15: Int, a16: Int, a17: Int, a18: Int, a19: Int, a20: Int,
  a21: Int, a22: Int, a23: Int
)

val mRow = summon[scala.deriving.Mirror.Of[Row]] // ok
val mElems = summon[scala.deriving.Mirror.Of[mRow.MirroredElemTypes]] // error

Output

-- Error: ----------------------------------------------------------------------
1 |summon[scala.deriving.Mirror.Of[mRow.MirroredElemTypes]] // error
  |                                                        ^
  |No given instance of type deriving.Mirror.Of[mRow.MirroredElemTypes] was found for parameter x of method summon in object Predef. Failed to synthesize an instance of type deriving.Mirror.Of[mRow.MirroredElemTypes]: 
  |	* class *: is not a generic product because it reduces to a tuple with arity 23, expected arity <= 22
  |	* class *: is not a generic sum because it does not have subclasses
1 error found

Expectation

we should be able to support generic tuples when arity is above 22. But the path to getting there would need some planning.

I propose that we could reinterpret MirroredElemLabels as a tuple of literal integer types for larger generic tuples, as there is currently no static constraint preventing this. e.g.

val res1: 
  scala.deriving.Mirror.Product{
    MirroredMonoType = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23);
    MirroredType = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23); 
    MirroredLabel = "Tuple23";
    MirroredElemTypes = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23);
    MirroredElemLabels = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22)
  } = anon$1@3f9e4811

Another alternative would be to add a new subtype of mirror: Mirror.Tuple, (probably also necessary to make explicit that the MirroredLabel no longer corresponds to a class name) and optionally a new Mirror.TupleOf[x *: y *: z *: EmptyTuple] summoner?

Either way the elem labels only act as unique identifiers, rather than having any runtime impact (and no you should not use the labels to access fields with java reflection, just use productIterator.)

[sjrd]

I believe the integers should start at 0, to match the values we can pass to the apply(i) method.

[nicolasstucki]

Probably a good idea to have them experimental to start with.