Mirror.SumOf not being provided when 0 inhabitants

[japgolly]

Compiler version

3.0.0-RC1

Minimized code

import scala.deriving.*
sealed trait X
summon[Mirror.Of[X]]

Output

[error] 59 |  summon[Mirror.Of[X]]
[error]    |                      ^
[error]    |no implicit argument of type deriving.Mirror.Of[X] was found for parameter x of method summon in object Predef

Expectation

X is a sealed trait. I expect a Mirror.SumOf[X] { type MirroredElemTypes = EmptyTuple } to be provided.

[bishabosha]

I am going to put this as an enhancement request, as we see this behaviour is by design:

Is this a sealed class or trait for which a sum mirror is generated?
It must satisfy the following conditions:
- it has at least one child class or object
  ...

taken from https://github.com/lampepfl/dotty/blob/5bb0e92b33cd96ac96d394068165b38e4ce5b035/compiler/src/dotty/tools/dotc/transform/SymUtils.scala#L100

In which case is it useful to have a Mirror for a sealed trait with no children?

[joroKr21]

In which case is it useful to have a Mirror for a sealed trait with no children?

It's just an induction base - it seems weird to treat this as a special case and exclude it

[bishabosha]

I think its fine to try this out

[japgolly]

In which case is it useful to have a Mirror for a sealed trait with no children?

I can try to did them out if you like, but I've also had a bunch of legitimate cases where I want to derive a valid type-class for a sealed trait with no concrete children. Also having no concrete children is also good for compile-time-only computation/logic.

[bishabosha]

I can try to did them out if you like, but I've also had a bunch of legitimate cases where I want to derive a valid type-class for a sealed trait with no concrete children. Also having no concrete children is also good for compile-time-only computation/logic.

And using Mirror.Sum is more appropriate in this case rather than some custom IsSealed typeclass? because there will still be no mirror generated if a single child is a plain class

[japgolly]

And using Mirror.Sum is more appropriate in this case rather than some custom IsSealed typeclass? because there will still be no mirror generated if a single child is a plain class

Yeah I think that does make sense and is most appropriate for two reasons:

1. In terms of the logic/math, treating a sealed trait with 0 children differently than sealed traits with >0 children means we're special-casing 0 and adding an exception to the general rule. Removing 0 as a special case makes the concept simpler. I kind of view it like us having a single List type in stdlib, as opposed to having two separate types: EmptyList and NonEmptyList
2. Re "no mirror generated if a single child is a plain class":
   • unfortunately that problem isn't completely solved because you could have one case class A child and one plain class B child and it sounds like the mirroring stuff will silently ignore B. So I'd say that's a more general problem because it affects the >0 existing cases too.
   • I wonder if it would make sense to prohibit or at least warn, when a non-(effectively)-sealed child extends a sealed parent?

[bishabosha]

@japgolly after trying to enable mirrors for sealed traits with 0 children, we have observed in the community build that there are already libraries that assume the sum mirror implies there must be a child. We suggest that if you want to deal with zero children sealed-types you could make a wrapper around Mirror that will be provided in the case where there are no children (and the type is still sealed).

[joroKr21]

@japgolly after trying to enable mirrors for sealed traits with 0 children, we have observed in the community build that there are already libraries that assume the sum mirror implies there must be a child. We suggest that if you want to deal with zero children sealed-types you could make a wrapper around Mirror that will be provided in the case where there are no children (and the type is still sealed).

That seems like a very weird thing to rely on. If they test that something does not compile we can ask them to remove those tests. Compiling more stuff should not really break anyone's code. Esp. considering that sealed traits with no children cannot be instantiated. Do you think there is a use case that could break by allowing mirrors for these kind of traits?