<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;">I can understand this proposal nite and I don't really think they're related to enums at all. You can today achieve the very same behaviour using an empty protocol.<br><br>protocol P { }<br><br>class A : P { }<br>class B : P { }<br>struct C : P { }<br><br>func test(value : P) { }<br><br>IMO, the proposed syntax will only create a shortcut for this. And we'd still need to test type and cast the to get anything useful. My question now is: is this such a common practice that justifies the shortcut?</div></div><div dir="ltr"><hr><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">From: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:swift-evolution@swift.org">Haravikk via swift-evolution</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Sent: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">16/05/2016 07:35 AM</span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">To: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:austinzheng@gmail.com">Austin Zheng</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Cc: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:swift-evolution@swift.org">Adrian Zubarev via swift-evolution</a>; <a href="mailto:frogcjn@163.com">Cao Jiannan</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Subject: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">Re: [swift-evolution] Union instead of Optional</span><br><br></div><br>> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:<br>> <br>> If A, B, and C are not related via protocol or class inheritance, then there is almost nothing you can do with value. Otherwise you still need to test against the concrete type using a case statement or a if-else ladder.<br><br>I think that a case statement or similar syntax will still be needed, and the case names would just be the types themselves. This would work best with support for type-narrowing, for example:<br><br> func someMethod(value:(A|B|C)) {<br> switch (value) {<br> case .A:<br> value.someMethodForTypeA()<br> case .B:<br> value.someMethodForTypeB()<br> case .C:<br> value.someMethodForTypeC()<br> }<br> }<br><br>A union should really just be though of as a lightweight, restricted form of enum that can be declared in a quick ad-hoc fashion, similar to how tuples are a simpler form of struct.<br><br>I’m generally a +1 for the feature, but I’d be interested to hear about how well equipped the compiler is for optimising something like this. In most cases an Optional covers what I need, and in more complex cases I’d probably declare overloads for each type (i.e- someMethod(value:A), someMethod(value:B) etc.); unions could make the latter case simpler, but will the compiler produce the same code behind the scenes, i.e- by isolating what’s unique to each type?<br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></body></html>