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 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, _)”. You still haven’t answered my question, though—what’s the use case for the feature you propose? > > > > > >> >>> >>> >>> 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