Unions are a no-go. https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>
> On Jun 30, 2016, at 5:00 PM, Andrew Bennett via swift-evolution > <[email protected]> wrote: > > How many of these use cases would be safely addressed if two Enum types could > be unioned to form a new type? > > It could use syntax similar to what is being proposed for existentials: > (A|B), or something like this: > > enum C: A, B {} > > Swift could generate code like this: > > enum A { > case A1, A2 > } > enum B { > case B1, B2 > } > enum C { > case A(Module.A) > case B(Module.B) > > init(_ a: Module.A) { self = .A(a) } > init(_ b: Module.B) { self = .B(b) } > > static let A1 = C(A.A1) > static let A2 = C(A.A2) > static let B1 = C(B.B1) > static let B2 = C(B.B2) > } > extension A { > init?(_ c: C) { > guard let case .A(a) = c else { return nil } > self = a > } > } > extension B { > init?(_ c: C) { > guard let case .B(b) = c else { return nil } > self = b > } > } > > > If I remember correctly there was already some proposals like this, they are > probably more thought out than this suggestion. I know I'd find that useful, > I don't think I'd want the exhaustibility implications of extending an enum > in another module. > > > On Friday, 1 July 2016, Marc Palmer via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > Hi, > > I too groan when faced with the lack of extensibility on enums. As a > potential framework writer, I'd like to be able to use an enum as a key to > dictionaries, supplying a minimum set of such enum cases, but allowing app > developers to add new ones they require. > > Having read the proposal however, I have a major concern and question the > entire idea. > > Given that there is unlikely to be a sane way to order the extended enum > cases supplied by other modules, we will never be able to rely on the > automatic ordinal values applied, nor their relative position in the natural > sequence, for there isn't one outside of the first set of cases in the > original definition. > > For many cases this may be fine, on the understanding that everything would > have to compile from source, but my understanding is that we don't want that > in future with ABI around the corner. Binary libraries would probably need to > bake in the value of e.g. Int enum cases. (I think?) > > I fear that if this proposal were implemented without some major restrictions > (such as never allowing use of rawValue), we would regret it and suffer for > example having to explicitly set enum case Int raw values for every case in > these enums in every module always, and suffer compilation errors when other > (maybe binary) modules change their explicit raw values and clash with other > modules. It could be a dependency nightmare. > > Essentially consigning extensible enums to never being useful for serialising > their raw values seems of limited use to me, as often you may not know you > need them to have unmoving raw values until it is too late and your code is > in the wild. > > Perhaps I am missing some secret sauce? > > -- > Marc Palmer > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
