<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">+1 for adding Java behaviour, it is something I have missed.<br class=""><br class="">The example would be:<br class=""><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">enum Suit: Int, CustomStringConvertible {</div><div class=""> case Hearts {</div><div class=""> var description: String { return “♥️" }</div><div class=""> }</div><div class=""> case Spades {</div><div class=""> var description: String { return “♠️" }</div><div class=""> }</div><div class=""> case Diamonds {</div><div class=""> var description: String { return “♦️" }</div><div class=""> }</div><div class=""> case Clubs {</div><div class=""> var description: String { return “♣️" }</div><div class=""> }</div><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span></div><div class=""> // ...</div>}</blockquote><div class=""><br class="">The compiler could automatically generate the switch statement if that was better than virtual dispatch.<br class=""><br class=""></div><br class=""><blockquote type="cite" class="">On 25 Mar 2016, at 2:42 AM, David Waite via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">In Java, the enum type behaves as an abstract class, sealed against the case members (which are singleton instance subclasses.)<br class=""><br class="">While Swift enums aren’t discrete types or singletons, it sounds like what you would like is the ability to have an enum behave as so - to be able to override base (or protocol extension) behavior with a particular enum case, and have that translated most likely into a switch statement (most likely - I suppose if you are using witness tables it could optimize the switch away)<br class=""><br class="">Actually with a protocol default behavior being overridden with a single enum case, this would give you functionality not possible today (referencing that protocol extension method)<br class=""><br class="">In Java, I exploit the enum behavior to implement the State design pattern quite a bit, but am limited as Java enums are singletons and thus should be isolated from state. Swift enums are even more powerful here, but doing this in switch statements is a pain for maintainability.<br class=""><br class="">I like the idea<br class=""><br class="">-DW<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Mar 23, 2016, at 4:13 AM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">If you've written enums before, you've no doubt noticed the irritating phenomenon of `switch self` being absolutely everywhere. I first discovered this in some of my very first Swift code, code so old we were still using the `T[]` shorthand syntax:<br class=""><br class=""> enum Suit: Int {<br class=""> case Hearts, Spades, Diamonds, Clubs<br class=""><br class=""> static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] }<br class=""><br class=""> var description: String {<br class=""> switch(self) {<br class=""> case .Hearts:<br class=""> return "♥️"<br class=""> case .Spades:<br class=""> return "♠️"<br class=""> case .Diamonds:<br class=""> return "♦️"<br class=""> case .Clubs:<br class=""> return "♣️"<br class=""> }<br class=""> }<br class=""><br class=""> var isRed: Bool {<br class=""> switch(self) {<br class=""> case .Hearts, .Diamonds:<br class=""> return true<br class=""> case .Spades, .Clubs:<br class=""> return false<br class=""> }<br class=""> }<br class=""> }<br class=""><br class="">It would be nice if we could somehow eliminate that. I have two suggestions:<br class=""><br class="">* Implicitly switch on `self` at the top level of a function or accessor (or at least an enum one with top-level `case` statements).<br class=""><br class=""> enum Suit: Int {<br class=""> case Hearts, Spades, Diamonds, Clubs<br class=""><br class=""> static var all = [ Hearts, Spades, Diamonds, Clubs ]<br class=""><br class=""> var description: String {<br class=""> case .Hearts:<br class=""> return "♥️"<br class=""> case .Spades:<br class=""> return "♠️"<br class=""> case .Diamonds:<br class=""> return "♦️"<br class=""> case .Clubs:<br class=""> return "♣️"<br class=""> }<br class=""><br class=""> var isRed: Bool {<br class=""> case .Hearts, .Diamonds:<br class=""> return true<br class=""> case .Spades, .Clubs:<br class=""> return false<br class=""> }<br class=""> }<br class=""><br class="">* Allow you to attach member definitions to particular cases. It would be an error if they didn't all define the same members, unless there was a top-level catchall.<br class=""><br class=""> enum Suit: Int {<br class=""> var isRed: Bool { return false }<br class=""><br class=""> case Hearts {<br class=""> let description: String { return "♥️" }<br class=""> let isRed: Bool { return true }<br class=""> }<br class=""> case Spades {<br class=""> let description: String { return "♠️" }<br class=""> }<br class=""> case Diamonds {<br class=""> let description: String { return "♦️" }<br class=""> let isRed: Bool { return true }<br class=""> }<br class=""> case Clubs {<br class=""> let description: String { return "♣️" }<br class=""> }<br class=""><br class=""> static var all = [ Hearts, Spades, Diamonds, Clubs ]<br class=""> }<br class=""><br class="">Any thoughts? This has, to be honest, bothered me since approximately the third day I used the language; I'd love to address it sooner or later.<br class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class="">_______________________________________________<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=""></blockquote><br class="">_______________________________________________<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=""></blockquote><br class=""></body></html>