<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Unions are a no-go.<div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md" class="">https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md</a></div><div class=""><br class=""></div><div class=""><br class=""><div style=""><blockquote type="cite" class=""><div class="">On Jun 30, 2016, at 5:00 PM, Andrew Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">How many of these use cases would be safely addressed if two Enum types could be unioned to form a new type?<div class=""><br class=""></div><div class="">It could use syntax similar to what is being proposed for existentials: <font face="monospace, monospace" class="">(A|B)</font>, or something like this:</div><div class=""><br class=""></div><div class=""><font face="monospace, monospace" class="">enum C: A, B {}</font></div><div class=""><br class=""></div><div class="">Swift could generate code like this:<div class=""><br class=""></div><div class=""><font face="monospace, monospace" class="">enum A {</font></div><div class=""><font face="monospace, monospace" class=""> case A1, A2</font></div><div class=""><font face="monospace, monospace" class="">}</font></div><div class=""><div class=""><font face="monospace, monospace" class="">enum B {</font></div><div class=""><font face="monospace, monospace" class=""> case B1, B2</font></div><div class=""><font face="monospace, monospace" class="">}</font></div><div class=""><font face="monospace, monospace" class="">enum C {</font></div><div class=""><font face="monospace, monospace" class=""> case A(Module.A)</font></div><div class=""><font face="monospace, monospace" class=""> case B(Module.B)<br class=""></font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class=""> init(_ a: Module.A) { self = .A(a) }</font></div><div class=""><font face="monospace, monospace" class=""> init(_ b: Module.B) { self = .B(b) }</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class=""> static let A1 = C(A.A1)</font></div><div class=""><font face="monospace, monospace" class=""> static let A2 = C(A.A2)<br class=""></font></div><div class=""><div class=""><font face="monospace, monospace" class=""> static let B1 = C(B.B1)</font></div><div class=""><font face="monospace, monospace" class=""> static let B2 = C(B.B2)</font></div></div><div class=""><font face="monospace, monospace" class="">}</font></div><div class=""><font face="monospace, monospace" class="">extension A {</font></div><div class=""><font face="monospace, monospace" class=""> init?(_ c: C) {</font></div><div class=""><font face="monospace, monospace" class=""> guard let case .A(a) = c else { return nil }</font></div><div class=""><font face="monospace, monospace" class=""> self = a</font></div><div class=""><font face="monospace, monospace" class=""> }</font></div><div class=""><font face="monospace, monospace" class="">}</font></div><div class=""><div class=""><font face="monospace, monospace" class="">extension B {</font></div><div class=""><font face="monospace, monospace" class=""> init?(_ c: C) {</font></div><div class=""><div class=""><font face="monospace, monospace" class=""> guard let case .B(b) = c else { return nil }</font></div><div class=""><font face="monospace, monospace" class=""> self = b</font></div></div><div class=""><font face="monospace, monospace" class=""> }</font></div><div class=""><font face="monospace, monospace" class="">}</font></div></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div>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.</div><div class=""><br class=""></div><div class=""><br class="">On Friday, 1 July 2016, Marc Palmer via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto" class=""><div class=""><div class=""><span style="background-color:rgba(255,255,255,0)" class="">Hi,</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">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. </span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">Having read the proposal however, I have a major concern and question the entire idea. </span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">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. </span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">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?)</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">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.</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">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. </span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">Perhaps I am missing some secret sauce?</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class="">--</span><div class=""><span style="background-color:rgba(255,255,255,0)" class="">Marc Palmer</span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div></div><blockquote type="cite" class=""><font class=""><span style="background-color:rgba(255,255,255,0)" class=""></span></font></blockquote></div></div></blockquote></div>
</div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>