On Fri, Jan 5, 2018 at 00:21 Cheyo Jimenez <ch...@masters3d.com> wrote:
> > > 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. >>>> <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. >>> >> >> 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. > I'm still not sure I understand. How can the machine know that it's dealing with an unknown case without first checking if it matches any known case? > > 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