<div dir="ltr">*like* types. I, at no point, said that they are types. <div><br></div><div>Pointing out what they can't do is not a great stance, in my opinion, because some of those things are perfectly reasonable but simply might not have been considered or attempted yet. I am *not* arguing that they are types. I am arguing that they are semantically different from static members. If they aren't, why not simply give us a means to pattern match over custom values and call it a day?</div><div><br></div><div>My point is that enum are special.</div><div><br></div><div>``` swift</div><div>enum Boolean {</div><div> case True, False</div><div>}</div><div>```</div><div><br></div><div>We could argue that `True` and `False` are just instances of Boolean. I will argue that you provide no significant state (Void) in either case to 'create' or 'choose' either `True` or `False`. You provide such a raw value to `Int` to create each instance but you do no such thing for an enum without an associate value. You do, however, provide a significant bit of state to enums with associated values. Both the case choses AND the state define identity, which places it between an enum without associated values and a struct/class/product type</div><div><br></div><div><div>``` swift</div><div>enum Optional<T> {</div><div> case Some(T)</div><div> case None</div><div>}</div><div>```</div></div><div><br></div><div>Again, I agree that they are not types. I disagree that they are just like `Int` Each case is a signifier between member value and type.</div><div>TJ</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 4, 2016 at 11:04 PM, Brent Royal-Gordon <span dir="ltr"><<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Because semantically they seem more like types unto themselves<br>
<br>
</span>But they aren't types.<br>
<br>
* You can't declare a variable/property/parameter of a particular case.<br>
* You can't constrain a generic type parameter to a case.<br>
* You can't cast to a case with `as` and friends or test for a case with `is`.<br>
* You can't conform different cases to different protocols.<br>
* You can't give different cases different members. (The associated value tuple is not a member; you can only access it with pattern matching.)<br>
<br>
There is nothing subtle or ambiguous about this. Swift does not even blur the line anywhere, except in the switch statement (which is full of ad-hoc magic) and in the now-corrected capitalization convention. Cases simply *are not* types. They are different values which may be stored in the same type, just as `Int(1)` and `Int(2)` are not different types.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</font></span></blockquote></div><br></div>