+1 for adding Java behaviour, it is something I have missed.
The example would be:
enum Suit: Int, CustomStringConvertible {
case Hearts {
var description: String { return “♥️" }
}
case Spades {
var description: String { return “♠️" }
}
case Diamonds {
var description: String { return “♦️" }
}
case Clubs {
var description: String { return “♣️" }
}
// ...
}
The compiler could automatically generate the switch statement if that was
better than virtual dispatch.
> On 25 Mar 2016, at 2:42 AM, David Waite via swift-evolution
> <[email protected]> wrote:
>
> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
