Looking into the commonly rejected proposals unions are only rejected in the general case because they "cannot and should not" be supported by the type system.
What I suggested is only for enums, and is possible in the type system, as demonstrated. On Friday, 1 July 2016, Austin Zheng <austinzh...@gmail.com <javascript:_e(%7B%7D,'cvml','austinzh...@gmail.com');>> wrote: > Unions are a no-go. > > https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md > > > On Jun 30, 2016, at 5:00 PM, Andrew Bennett via swift-evolution < > swift-evolution@swift.org> 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 < > swift-evolution@swift.org> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution