> 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

Reply via email to