[swift-evolution] [Idea] Find alternatives to `switch self`

David Waite david at alkaline-solutions.com
Thu Mar 24 10:42:01 CDT 2016


In Java, the enum type behaves as an abstract class, sealed against the case members (which are singleton instance subclasses.)

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)

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)

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.

I like the idea

-DW


> On Mar 23, 2016, at 4:13 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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:
> 
>    enum Suit: Int {
>        case Hearts, Spades, Diamonds, Clubs
> 
>        static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] }
> 
>        var description: String {
>            switch(self) {
>            case .Hearts:
>                return "♥️"
>            case .Spades:
>                return "♠️"
>            case .Diamonds:
>                return "♦️"
>            case .Clubs:
>                return "♣️"
>            }
>        }
> 
>        var isRed: Bool {
>            switch(self) {
>            case .Hearts, .Diamonds:
>                return true
>            case .Spades, .Clubs:
>                return false
>            }
>        }
>    }
> 
> It would be nice if we could somehow eliminate that. I have two suggestions:
> 
> * Implicitly switch on `self` at the top level of a function or accessor (or at least an enum one with top-level `case` statements).
> 
>    enum Suit: Int {
>        case Hearts, Spades, Diamonds, Clubs
> 
>        static var all = [ Hearts, Spades, Diamonds, Clubs ]
> 
>        var description: String {
>        case .Hearts:
>            return "♥️"
>        case .Spades:
>            return "♠️"
>        case .Diamonds:
>            return "♦️"
>        case .Clubs:
>            return "♣️"
>        }
> 
>        var isRed: Bool {
>        case .Hearts, .Diamonds:
>            return true
>        case .Spades, .Clubs:
>            return false
>        }
>    }
> 
> * 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.
> 
>    enum Suit: Int {
>        var isRed: Bool { return false }
> 
>        case Hearts {
>            let description: String { return "♥️" }
>            let isRed: Bool { return true }
>        }
>        case Spades {
>            let description: String { return  "♠️" }
>        }
>        case Diamonds {
>            let description: String { return  "♦️" }
>            let isRed: Bool { return true }
>        }
>        case Clubs {
>            let description: String { return  "♣️" }
>        }
> 
>        static var all = [ Hearts, Spades, Diamonds, Clubs ]
>    }
> 
> 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.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list