> On Jan 5, 2018, at 4:42 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > > On Fri, Jan 5, 2018 at 03:11 Jonathan Hull <jh...@gbis.com > <mailto:jh...@gbis.com>> wrote: >> On Jan 4, 2018, at 11:02 PM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> >> >> On Fri, Jan 5, 2018 at 01:56 Jonathan Hull <jh...@gbis.com >> <mailto:jh...@gbis.com>> wrote: >>> On Jan 4, 2018, at 10:31 PM, Xiaodi Wu via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Fri, Jan 5, 2018 at 00:21 Cheyo Jimenez <ch...@masters3d.com >>> <mailto:ch...@masters3d.com>> wrote: >> >>> >>> On Jan 4, 2018, at 4:37 PM, Xiaodi Wu <xiaodi...@gmail.com >>> <mailto:xiaodi...@gmail.com>> wrote: >>> >> >>>> On Thu, Jan 4, 2018 at 19:29 Cheyo J. Jimenez <ch...@masters3d.com >>>> <mailto:ch...@masters3d.com>> wrote: >>>> >>>> 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? >> >> >> I had the same thought as Cheyo. It isn’t a deal breaker… I like the >> compromise, but I would prefer it trigger only on an actual unknown case (as >> opposed to acting like default). I like to break failure cases out at the >> top when possible. I don’t see any good reason not to support that style. >> >> To answer your question, in the naive sense, it basically is the same >> question as asking if it is a known case (and then taking the inverse). That >> doesn’t mean actually checking each case separately though. For example, if >> the enum cases are internally represented as an unsigned integer, and they >> are all together in a block, the compiler could simply check that it is >> greater than the max known value. You could probably even do a bit mask >> comparison in some cases... >> >> These are obvious optimizations, but why does this require new syntax? > > I am not sure I understand what you are asking. There isn’t additional > syntax. We are just arguing over the name + behavior of ‘unexpected:’. You > want it to behave like ‘default’ and I am saying that stops the use case I > mention above. > > Cheyo said he wants “unexpected case” to work in pattern matching, as well as > a new “case *” that is distinct from “case _”. This is additional syntax. > When asked what the use case was for these suggestions, he said he wants to > distinguish between known and unknown cases at the beginning of the switch. > > > >> What do you gain from writing the unknown case first? > > I know where to look for the failure cases. I also tend put a bunch of guard > statements near the beginning of a function. It is just a programming style. > > With my behavior of ‘unexpected:’ you can put it wherever you want. Why > limit that by forcing it to go at the end? > > As pointed out earlier (by one of the core team members, I think), meaningful > resilience would mean that the unexpected or unknown case should have useful > work executed at runtime; the intention is that the user *shouldn’t* be > treating it as a runtime “failure case,” as it effectively makes adding an > enum case a change that is incompatible with existing binaries (i.e., not > terribly resilient). > > As you and I seem to agree, reaching an unexpected case requires at least > notionally considering which cases are expected in the first place. This is > the dictionary definition of a default, and Swift usage is to put the default > case at the end of a switch statement. Adding new syntax as Cheyo suggests to > enable putting it elsewhere, merely for “style,” doesn’t seem to pass the bar > for new syntax, nor is it consistent with existing Swift usage.
I agree with the new syntax suggestion is premature. I would hope that the proposed runtime "Deriving collections of enum cases” <https://github.com/apple/swift-evolution/pull/114/files> function also has a compile time version which we can then use to match all the known cases at compile time. I am happy with SE 0192 as it stands now. > >> Isn't this basically the same thing as asking for the ability to write the >> default case first, a frequently suggested and rejected syntax addition? > > No. I don’t think I have ever heard that asked for, > > It has been asked for more than once on this list. > > but putting default in a different place has a different meaning. The way I > read a switch statement anyway is that it tries each case until it find one > that matches. Default matches everything, so it has to go at the end (since > it will always match and nothing afterwards will be tried). > > Having ‘unexpected:’ also match known/expected cases is problematic as a > mental model. I think that is just an artifact of the original proposal > using default. There is no reason 'unexpected:’ should have to handle known > cases as well… let’s just have it trigger on unexpected ones. > > I don’t think anyone is proposing that the unexpected or unknown case should > also match expected cases. Where did you see such a suggestion? > > Thanks, > Jon
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
