Include sealed traits and classes as elements of Sum Mirrors

[odersky]

Addresses feature request #161

lampepfl/dotty-feature-requests#161

This is just the immediate fix. We need more tests and use cases to see whether it works. @dwijnand if we can get some corrobation by Wednesday we might be able to roll this into 3.0. Otherwise it will have to wait.

[julienrf]

Thanks for the quick fix!

[julienrf]

Suggested change

	* - all of its children are generic products, singletons, or sealed traits ar classes
	* - all of its children are generic products, singletons, or sealed traits or classes

[julienrf]

Can we maybe add another test like the following?

val mirrorA = summon[Mirror.Of[A]]
summon[mirrorA.MirroredElemTypes <:< (C *: B *: EmptyTuple)]

[odersky]

As the failure of the Akka CB shows, I have overlooked something. The trait hierarchy can be an arbitrary graph. Consider:

sealed trait A
sealed trait B extends A
sealed trait C extends A
case class D() extends B, C
case class E() extends B, C

Now if we generate the ordinal method, we get unreachable cases. That's what we observe when trying to build akka.

I see currently three ways to address this:

1. Continue with Synthesise Mirror.Sum for nested hierarchies #11686. This means that mirrors will show elements that are not in the children of the base trait. This is risky since it might break some assumptions of code that does typeclass derivation.
2. Continue with the scheme in this PR, but only consider sealed child traits that dominate their children. I.e. their children are not at the same children of the parent trait or of another child trait. In other words the inheritance graph must be a tree. This is also risky since it might break an assumption in typeclass derivation code that elements of sum mirrors are always product mirrors.
3. As a minimal solution, simply ignore sealed subtraits that don't introduce new children. That is, we would allow

   sealed trait A
   sealed trait B extends A
   case class C() extends A
   case class D() extends A, B

   Here, the children of A are B, C, and D, and the mirror elements are C and D. B is ignored since it adds no
   new children. This is also risky in that typeclass derivation code might assume that mirror elements are in a one to one correspondence with children. But it's probably less risky than (1) and (2)

[julienrf]

1. Continue with Synthesise Mirror.Sum for nested hierarchies #11686. This means that mirrors will show elements that are not in the children of the base trait. This is risky since it might break some assumptions of code that does typeclass derivation.

Which assumptions do you think about?

[odersky]

Which assumptions do you think about?

For instance, if I have typeclass derivation code that consults the children annotation at runtime I get a mismatch between that and what the mirror claims. Or if the code assumes that all mirror elements have the sum as direct parent type.

[lrytz]

(Dale is OOO this week)

[japgolly]

if we can get some corrobation by Wednesday we might be able to roll this into 3.0
(Dale is OOO this week)

I'm happy to put my hand up for that. Let me know what you need!

[japgolly]

Regarding the approach to implementation, I have another one to add to the 3 ideas above.

(4) Have two means of summoning a mirror, both with simple algorithms:

1. Gather all product children transitively. This is the most commonly useful case so could be the default for the existing Mirror.Of. In the Akka example above:

summon[Mirror.Of[A]].MirroredElemTypes =:= (C, D)
summon[Mirror.Of[B]].MirroredElemTypes =:= (D)

2. Gather sub-types directly and non-transitively, regardless of whether the sub-type is a product or a sum. We could give this a different type Mirror.DirectlyOf and have users explicitly opt-in to this algorithm. In the Akka example above:

summon[Mirror.DirectlyOf[A]].MirroredElemTypes =:= (B, C, D)
summon[Mirror.DirectlyOf[B]].MirroredElemTypes =:= (D)

In my experience with automatic derivation, it's always one of the above two I want. Which one depends on what I'm deriving.

[julienrf]

@japgolly Interesting. I’m not sure whether we can change this now but I agree with your analysis: those two ways of retrieving the subclasses are the most common in my experience as well.

[odersky]

I think it's probably best for now to continue with #11686. But since Dale is OOO this weak there's no chance for it to make it into RC2. In my opinion, even if we could work on this right now, it would be too big a change to make so short before the release date.