> On Jan 4, 2018, at 2:55 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
>
> On Thu, Jan 4, 2018 at 17:15 Cheyo J. Jimenez <ch...@masters3d.com
> <mailto:ch...@masters3d.com>> wrote:
>> On Jan 4, 2018, at 11:53 AM, Xiaodi Wu <xiaodi...@gmail.com
>> <mailto:xiaodi...@gmail.com>> wrote:
>>
>>
>> On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez <ch...@masters3d.com
>> <mailto:ch...@masters3d.com>> wrote:
>>
>>
>> On Jan 4, 2018, at 10:49 AM, Jordan Rose <jordan_r...@apple.com
>> <mailto:jordan_r...@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.
>
> I was thinking of a generalized `unknown case` pattern but that is out of
> scope for this proposal.
> <https://github.com/apple/swift-evolution/pull/777/files#diff-a68dc745ee86d09566b232b6954c5158R321>
>
>
> switch excuse {
> case .eatenByPet :
> //…
> unknown case:
> // …
> case _:
> // …
> }
>
>>
>> Should there be something like `case *` that would capture all currently
>> known cases during compile time? case * and case _ would be the same in
>> exhaustive enums.
>
> This is why I was suggesting another pattern that only captures known cases
> at compile time:
>
> switch excuse {
> case .eatenByPet :
> //…
> case * : // All cases captured at compile time.
> // …
> unknown case:
> // …
> }
>
> Sorry, I don’t understand. However you spell it, what is your use case for
> this? The stated purpose of “unknown case” is to gain compile-time
> exhaustiveness testing, but this would not allow for that.
switch (excuse, notifiedTeacherBeforeDeadline) {
case (.eatenByPet, true):
// …
case (.thoughtItWasDueNextWeek, true):
// …
case (unknown case, true):
// …
case (_, false):
// …
}
Im referring to the future direction section in the new PR
<https://github.com/jrose-apple/swift-evolution/blob/6061c01fb4a6d742ba7213f46979c9b82891fc14/proposals/0192-non-exhaustive-enums.md#future-directions>.
The above example if from there.
I am fine with `unknown case` being required to be at the end of the switch for
now.
I think of `unknown case` as a pattern that only matches unknown cases no
matter where on the switch it is.
This is why I do not think that `default unknown` would work well once `unknown
case` can be used a pattern.
We can start a new thread on this if you’d like.
>
>
>
>>
>>
>>>
>>> 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...@gmail.com
>>>> <mailto:xiaodi...@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 <ch...@masters3d.com
>>>> <mailto:ch...@masters3d.com>> wrote:
>>>>
>>>>
>>>> On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>> On Jan 2, 2018, at 18:07, Jordan Rose <jordan_r...@apple.com
>>>>>> <mailto:jordan_r...@apple.com>> wrote:
>>>>>>
>>>>>> [Proposal:
>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>>>>>>
>>>>>> <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
>>>>> <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@swift.org <mailto:swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
