Enum and equivalent class hierarchy do not generate same type signature

Compiler version

Version 2.3.1

Minimized code

I have created two examples of an HList using this Enum:

enum Tup:
  case EmpT
  case TCons[H, T <: Tup](head: H, tail: T)

import Tup.*

and what I assume is the equivalent case class hierarchy:

sealed trait Tup
case object EmpT extends Tup
case class TCons[H, T <: Tup](head: H, tail: T) extends Tup

//import Tup.*

In both cases I use the same code:

val tup1: TCons[1, TCons[2,  EmpT.type]] = TCons(1, TCons(2,  EmpT))
val tup3 = TCons(3, TCons(3,  EmpT))

println(split(tup1))
println(split(tup3))

The full code can be found here:

• Using enums
• Using sealed trait

Output

I expected both examples to compile and run. However in the Enum version, in the last line I get:

    cannot reduce inline match with
     scrutinee:  Playground.tup3 : (Playground.tup3 : Playground.Tup)
     patterns :  case _:Playground.Tup#EmpT.type
                 case cons @ _:Playground.Tup.TCons[_ @  >: Nothing <: Any, _ @  >: Nothing <: Any]

Expectation

I expect both versions to generate the same type inference. My IDE shows that for the Enum version, the HLIst will have the the generic type Tup. For the sealed trait version, the complete definition of HList will be retained.

I would also expect the HList to retain its value types. For example, My IDE shows, which I assume is what the compiler inferred:

   val tup2: TCons[Int, TCons[Int, EmpT.type]] = 1 +: 2 +: EmpT

in my opinion should be:

   val tup2: TCons[1, TCons[2, EmpT.type]] = 1 +: 2 +: EmpT

For the first issue this may not be a bug. If it is not, and maybe I missed it, this difference could be documented.

The second is a question. If it is warranted, I can open another issue.

TIA

[bishabosha]

This is as documented

Note that the type of the expressions above is always Option. Generally, the type of a enum case constructor application will be widened to the underlying enum type, unless a more specific type is expected. This is a subtle difference with respect to normal case classes. The classes making up the cases do exist, and can be unveiled, either by constructing them directly with a new, or by explicitly providing an expected type.

[bishabosha]

You can use a union type of the enum cases as an upper bound if you want precise types