> While that's great, I was hoping it would be like in Rust, where each enum variant can declare its own state components, but unfortunately it seems to be more like Java: same state for all variants.
Yes, the enhanced enums we shipped in 2.17 are like Java enums.
I say "style" here because object-oriented languages like Dart can already mostly model sum types using subclasses. What you need to get the rest of the way there is basically just:
1. Sealed types so that the compiler can check for exhaustiveness when you match over all of the subclasses.
2. A nice pattern matching syntax to let you discriminate between the subclasses and destructure them.
3. Ideally, a nice lightweight syntax for defining a sum type family as a superclass and set of subclasses, though this is relatively less critical.
We're hard at work on this, but pattern matching in general is a pretty large feature and retrofitting it into a language whose syntax wasn't initially designed around it is a challenge.
I'm very excited about macros too. That's another large, difficult feature, but one that I hope will provide a lot of power to users and make the entire ecosystem more valuable over time.
Any thoughts on the freezed package [0]? That's what I use currently for ADTs and exhaustive pattern matching on them, would be cool to see similar syntax in the official implementation.
That feels like quite an awkward way to squash tagged unions into a class structure... But maybe it will work. I would say special syntax for it probably is critical because defining an entire class for each variant does not sound like fun!
> That feels like quite an awkward way to squash tagged unions into a class structure... But maybe it will work.
It's what Scala and Kotlin do and I think it's a fairly natural mapping. (Swift takes a different approach with their enums).
> defining an entire class for each variant does not sound like fun!
If you come at it expecting the brevity of ML, yes, it's not. But if you accept that those variants are real classes and may also have their instance methods, documentation comments on the fields, etc. then the overhead starts to feel less onerous.
Yes, the enhanced enums we shipped in 2.17 are like Java enums.
We are also working on support for pattern matching and algebraic datatype-style programming: https://github.com/dart-lang/language/blob/master/working/05...
I say "style" here because object-oriented languages like Dart can already mostly model sum types using subclasses. What you need to get the rest of the way there is basically just:
1. Sealed types so that the compiler can check for exhaustiveness when you match over all of the subclasses.
2. A nice pattern matching syntax to let you discriminate between the subclasses and destructure them.
3. Ideally, a nice lightweight syntax for defining a sum type family as a superclass and set of subclasses, though this is relatively less critical.
We're hard at work on this, but pattern matching in general is a pretty large feature and retrofitting it into a language whose syntax wasn't initially designed around it is a challenge.
I'm very excited about macros too. That's another large, difficult feature, but one that I hope will provide a lot of power to users and make the entire ecosystem more valuable over time.