[swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Xiaodi Wu]

On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez <cheyo at masters3d.com> wrote:

>
>
> On Jan 4, 2018, at 10:49 AM, Jordan Rose <jordan_rose at apple.com> wrote:
>
> I'll admit I hadn't thought of using "unknown default" (or "default
> unknown"). I don't think that's terrible, but I mildly prefer `unknown
> case` because it builds on the "pun" that enum elements are also defined
> using 'case'. If anything hits this part of the switch, it really will be
> an "unknown case", i.e. a statically-unknown enum element.
>
> To Cheyo's point, if this *were* to be a single token I'd probably spell
> it #unknown, like #available. Then we'd have `case #unknown:` and something
> that naturally expands to other pattern positions. I found that less
> aesthetically pleasing, though, and so a context-sensitive keyword seemed
> like the way to go.
>
> (For the record, though, I wouldn't describe `case _` as a special case of
> `default`. They do exactly the same thing, and `_` is a useful pattern in
> other contexts, so if anything the current `default` should be thought of
> as syntactic sugar for `case _`.)
>
>
> Can case _ be mixed with unknown case? How can we match all compile time
> known cases but exclude future cases?
>

What’s your use case for that? That eliminates the possibility of “unknown
case” giving you compile-time warnings for subsequently added cases, which
was the entire purpose of adding the syntax in the first place.

Should be something like `case *` that would capture all currently known
> cases during compile time? case * and case _ would be the same in
> exhaustive enums.
>
>
>
> I'll add these points to the "Alternatives Considered" section in the PR
> later today.
>
> Jordan
>
>
> On Jan 3, 2018, at 22:56, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> As has already been said, “case unknown” is source-breaking because it
> conflicts with any real cases named “unknown”; “\unknown” looks like a key
> path but isn’t, and I wonder if it would potentially conflict with existing
> key paths.
>
> In any case, my point was not to bikeshed the “unknown” part, but to ask
> whether any consideration had been made to have the feature presented as a
> flavor of default instead of a flavor of case.
>
> On Wed, Jan 3, 2018 at 23:57 Cheyo Jimenez <cheyo at masters3d.com> wrote:
>
>>
>>
>> On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> This is a very nice revision. One bikeshedding thought:
>>
>> Since "unknown case" is presented as a special kind of "default", can't
>> be mixed with "default", and can't be used in case patterns, why not
>> "default unknown" (or "unknown default") instead of "unknown case"?
>>
>>
>> `case _ :` is already a special case of default.
>> I’d rather have `case unknown :`
>> `unknown case :` is weird because of the order of `case`.
>>
>> Another alternative is `case \unknown :`
>> `\unknown` would also allow pattern matching.
>>
>>
>>
>>
>>
>> On Wed, Jan 3, 2018 at 8:05 PM, Jordan Rose via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> On Jan 2, 2018, at 18:07, Jordan Rose <jordan_rose at apple.com> wrote:
>>>
>>> [Proposal:
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>>> ]
>>>
>>> Whew! Thanks for your feedback, everyone. On the lighter side of
>>> feedback—naming things—it seems that most people seem to like '*@frozen*',
>>> and that does in fact have the connotations we want it to have. I like it
>>> too.
>>>
>>> More seriously, this discussion has convinced me that it's worth
>>> including what the proposal discusses as a *'future' case*. The key
>>> point that swayed me is that this can produce a *warning* when the
>>> switch is missing a case rather than an *error,* which both provides
>>> the necessary compiler feedback to update your code and allows your
>>> dependencies to continue compiling when you update to a newer SDK. I know
>>> people on both sides won't be 100% satisfied with this, but does it seem
>>> like a reasonable compromise?
>>>
>>> The next question is how to spell it. I'm leaning towards `unexpected
>>> case:`, which (a) is backwards-compatible, and (b) also handles "private
>>> cases", either the fake kind that you can do in C (as described in the
>>> proposal), or some real feature we might add to Swift some day. `unknown
>>> case:` isn't bad either.
>>>
>>> I too would like to just do `unknown:` or `unexpected:` but that's
>>> technically a source-breaking change:
>>>
>>> switch foo {
>>> case bar:
>>>   unknown:
>>>   while baz() {
>>>     while garply() {
>>>       if quux() {
>>>         break unknown
>>>       }
>>>     }
>>>   }
>>> }
>>>
>>>
>>> Another downside of the `unexpected case:` spelling is that it doesn't
>>> work as part of a larger pattern. I don't have a good answer for that one,
>>> but perhaps it's acceptable for now.
>>>
>>> I'll write up a revision of the proposal soon and make sure the core
>>> team gets my recommendation when they discuss the results of the review.
>>>
>>> ---
>>>
>>> I'll respond to a few of the more intricate discussions tomorrow,
>>> including the syntax of putting a new declaration inside the enum rather
>>> than outside. Thank you again, everyone, and happy new year!
>>>
>>>
>>> I ended up doing these in the opposite order, writing up the new
>>> proposal first and not yet responding to the discussion that's further out.
>>> You can read my revisions at
>>> https://github.com/apple/swift-evolution/pull/777.
>>>
>>> In particular, I want to at least address:
>>> - Dave D and Drew C's points about versioned libraries / linking
>>> semantics of modules.
>>> - Jason M's point about migration
>>> and I'll do one more pass over the thread to see if there's anything
>>> else I didn't address directly. (That doesn't mean everyone who disagrees,
>>> just messages where I think there's more I can do to explain why the
>>> proposal is the way it is.)
>>>
>>> Jordan
>>>
>>> P.S. Enjoying the Disney references. Thanks, Nevin and Dave. :-)
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>> _______________________________________________
>> 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/20180104/9c6cf034/attachment.html>