*like* types. I, at no point, said that they are types. 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?
My point is that enum are special. ``` swift enum Boolean { case True, False } ``` 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 ``` swift enum Optional<T> { case Some(T) case None } ``` 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. TJ On Mon, Apr 4, 2016 at 11:04 PM, Brent Royal-Gordon <br...@architechies.com> wrote: > > Because semantically they seem more like types unto themselves > > But they aren't types. > > * You can't declare a variable/property/parameter of a particular case. > * You can't constrain a generic type parameter to a case. > * You can't cast to a case with `as` and friends or test for a case with > `is`. > * You can't conform different cases to different protocols. > * You can't give different cases different members. (The associated value > tuple is not a member; you can only access it with pattern matching.) > > 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. > > -- > Brent Royal-Gordon > Architechies > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution