Avatar
I think there are definitely places where having cases be a subtype of an enum make sense, but I don't think it makes sense for *all* cases to be subtypes. For example, with "biased" containers like Optional and Result, it makes sense for the "right" side to be a subtype and the "wrong" side to be explicitly constructed, IMO. If the types of cases overlap, it would also be *ambiguous* which case ought to be constructed when the payload is converted to the enum type—remember that enums are sums, not unions, and that's important for composability and uniform behavior with generics. I would be fine allowing enum subtyping with some opt-in attribute, e.g.: enum Optional<Wrapped> { sub case some(wrapped) case none } enum Result<Wrapped> { sub case ok(wrapped) case error(Error) // not a subtype } enum JSON { // OK for these to all be sub-cases, since they don't overlap sub case string(String), number(Double), array([JSON]), object([String: JSON]), null } enum Either<T, U> { // Error: sub cases potentially overlap sub case left(T), right(U) } -Joe
3:51 AM
なんかちょっと言ってることと違う気がする。