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 
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to