> On Jan 4, 2018, at 4:37 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
>
> On Thu, Jan 4, 2018 at 19:29 Cheyo J. Jimenez <ch...@masters3d.com> wrote:
>>> On Jan 4, 2018, at 3:50 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>
>>>
>>> On Thu, Jan 4, 2018 at 18:39 Cheyo J. Jimenez <ch...@masters3d.com> wrote:
>>>>
>>>>> 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> wrote:
>>>>>>> On Jan 4, 2018, at 11:53 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez <ch...@masters3d.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Jan 4, 2018, at 10:49 AM, Jordan Rose <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.
>>>>>>
>>>>>> 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. 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.
>>>
>>> The reason I put forward “default unknown” is precisely because the
>>> proposed feature *cannot* be used in a pattern and therefore seems more apt
>>> as not a case.
>>>
>>
>> It can not be used in a pattern now but you could in the future if left as
>> `case`.
>>
>>
>>> It actually makes it more natural to use in the given example above because
>>> “default unknown” could actually be used to provide compile-time
>>> exhaustiveness checking for such a tuple pattern, whereas without being
>>> able to use “unknown case” in a pattern you can’t write “case (unknown
>>> case, _)”.
>>
>> The way `unknown case` enforces compile-time exhaustiveness is by only
>> matching unknown cases. The implementation may be more close to default by
>> the virtue of being forced to go at the end of the switch statement now but
>> that should not dictate the user experience.
>
> We seem to agree that, by virtue of not supporting use in a pattern and being
> placed at the end, the feature is a flavor of default. I’m still not sure I
> understand why you believe it should not be a flavor of default going forward.
>
>>>
>>> You still haven’t answered my question, though—what’s the use case for the
>>> feature you propose?
>>
>> My use case would be distinguishing between compile time known cases vs
>> “future only” cases (or unknown cases).
>
> I understand that the feature you propose would allow you to make such a
> distinction, but again, what is your use case for doing so?
Breaking out early by checking unknown cases first. I admit this is not deal
breaker, just a different style I’d like to see supported in the future.
>
>> This depends on generalized `unknown case` patterns which is out of scope. I
>> am happy to talk more about this on a different thread when this proposal
>> gets approved.
>>
>>
>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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> 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>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution
>>>>>>>>>>>> <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> wrote:
>>>>>>>>>>>>>> On Jan 2, 2018, at 18:07, Jordan Rose <jordan_r...@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@swift.org
>>>>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> swift-evolution mailing list
>>>>>>>>>>>> swift-evolution@swift.org
>>>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
