<div dir="ltr"><p>Looks like you’re coming close to @cjwirth’s approach of using a private <code>struct</code> to represent the various combinations of values that a single enum could represent:</p>
<p><a href="http://cjwirth.com/2016/03/14/easier-enums/">http://cjwirth.com/2016/03/14/easier-enums/</a></p>
<p>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’ <code>switch self</code> is potentially liveable with.</p>
<p>When it gets to writing four or more for a single <code>enum</code>, 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 <code>enum</code>, and maybe there’s some other amendments the problem’s object graph that may help.</p>
<p>—</p>
<p>Scott</p>
<br><br><div class="gmail_quote"><div dir="ltr">On Wed, 23 Mar 2016 at 10:14 Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<br>
enum Suit: Int {<br>
case Hearts, Spades, Diamonds, Clubs<br>
<br>
static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] }<br>
<br>
var description: String {<br>
switch(self) {<br>
case .Hearts:<br>
return "♥️"<br>
case .Spades:<br>
return "♠️"<br>
case .Diamonds:<br>
return "♦️"<br>
case .Clubs:<br>
return "♣️"<br>
}<br>
}<br>
<br>
var isRed: Bool {<br>
switch(self) {<br>
case .Hearts, .Diamonds:<br>
return true<br>
case .Spades, .Clubs:<br>
return false<br>
}<br>
}<br>
}<br>
<br>
It would be nice if we could somehow eliminate that. I have two suggestions:<br>
<br>
* 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>
<br>
enum Suit: Int {<br>
case Hearts, Spades, Diamonds, Clubs<br>
<br>
static var all = [ Hearts, Spades, Diamonds, Clubs ]<br>
<br>
var description: String {<br>
case .Hearts:<br>
return "♥️"<br>
case .Spades:<br>
return "♠️"<br>
case .Diamonds:<br>
return "♦️"<br>
case .Clubs:<br>
return "♣️"<br>
}<br>
<br>
var isRed: Bool {<br>
case .Hearts, .Diamonds:<br>
return true<br>
case .Spades, .Clubs:<br>
return false<br>
}<br>
}<br>
<br>
* 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>
<br>
enum Suit: Int {<br>
var isRed: Bool { return false }<br>
<br>
case Hearts {<br>
let description: String { return "♥️" }<br>
let isRed: Bool { return true }<br>
}<br>
case Spades {<br>
let description: String { return "♠️" }<br>
}<br>
case Diamonds {<br>
let description: String { return "♦️" }<br>
let isRed: Bool { return true }<br>
}<br>
case Clubs {<br>
let description: String { return "♣️" }<br>
}<br>
<br>
static var all = [ Hearts, Spades, Diamonds, Clubs ]<br>
}<br>
<br>
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>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>