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

[Xiaodi Wu]

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/8b0497ad/attachment.html>