> On Jan 5, 2018, at 00:11, Jonathan Hull via swift-evolution
> <swift-evolution@swift.org> 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.
>
>
>> 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?
>
>> 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, 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'm going to repeat this from my reply to Cheyo earlier: I really, really don't
want recompiling code against a different version of the library to pick a
different case than it did before.
(This might be a weak argument since overload resolution, protocol conformance
checking, etc can end up picking a different declaration than it did before.
But I would hope that the overloads or alternate protocol witnesses at least
"do the same thing" in normal situations, if possibly more efficiently. I
wouldn't expect that for `unknown case` vs. `default` if you actually had both
of them.)
The reason `unknown case` has to match known cases is, again, for source
compatibility. If the compiler only produces a warning, rather than an error,
when you're missing a case, it has to do something if that case comes up. The
most reasonable thing for it to do (in the absence of a separate `default`) is
for that to go to the `unknown case`, just like it would have with the last
version of the app. That's why I chose to associate it with `default` in the
proposal, not the other way around.
Jordan
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
