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

Scott Matthewman scott at matthewman.net
Wed Mar 23 06:01:40 CDT 2016


Looks like you’re coming close to @cjwirth’s approach of using a private
struct to represent the various combinations of values that a single enum
could represent:

http://cjwirth.com/2016/03/14/easier-enums/

It’s always tricky when coming up with generic and simple examples to
illustrate a pain point; I think in both your case and Caesar’s, enums’ switch
self is potentially liveable with.

When it gets to writing four or more for a single enum, the value object
approach has definite benefits – but it also feels as if it’s maybe a sign
that we’re leaning too heavily on the enum, and maybe there’s some other
amendments the problem’s object graph that may help.

—

Scott


On Wed, 23 Mar 2016 at 10:14 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160323/08444640/attachment.html>


More information about the swift-evolution mailing list