[swift-evolution] My personal beef with leading-dot syntax

[T.J. Usiyan]

*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 <brent at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160404/44fd7e17/attachment.html>