<div dir="ltr"><div>Hello swift-evolution:</div><div><br></div>Based on recent conversations on the list, I&#39;d like to float a trial balloon: an &quot;enum class&quot; kind which is analogous to classes in the same way existing enums are to structs. This is a data type which allows the user to define a number of cases, like enums, and can participate in pattern matching and exhaustivity analysis. Instances of an enum class are reference types, which enables (for example) graph nodes with a built-in concept of identity.<div><br></div><div>To be slightly more fanciful, perhaps such a kind could be treated as an &#39;almost-final&#39; class, with each case being a nested type which is defined as a final subclass of the enum class. Cases could then define their own behavior:</div><div><br></div><div>enum class GraphNode {</div><div>  case Node(left: GraphNode, right: GraphNode) {</div><div>    override func foo() { ... }</div><div>    func nodeSpecificMethod() { ... }</div><div>  }</div><div><br></div><div>  case Leaf {</div><div>    override func foo() { ... }</div><div>    func leafSpecificMethod() { ... }</div><div>  }</div><div><br></div><div>  func foo() { ... }</div><div>}</div><div><br></div><div>let x : GraphNode = GraphNode.newEmptyTree()</div><div>let y : GraphNode = GraphNode.Node(l, r)</div><div>let z : GraphNode = GraphNode.Leaf()</div><div>let a : GraphNode.Leaf = GraphNode.Leaf()</div><div><br></div><div>Enum classes would not be subclassible, and extensions would not be able to define new cases (as is the case with normal enums at the present time).</div><div><br></div><div>My superficial analysis seems to suggest that this would solve two issues: providing a reference-semantics type with all the pattern matching functionality of current enums, and providing a construct for modeling case-class style ADTs where each case should be treated as a subtype (as has been occasionally proposed).</div><div><br></div><div>I would like feedback as to:</div><div>- Whether this is something that would be useful enough to justify additional language features</div><div>- Whether this is something that would be theoretically well-founded and elegant</div><div><br></div><div>Thanks for your time, and have a great day!</div><div><br></div><div>Austin</div><div><br></div><div><br></div></div>