> On Jan 3, 2018, at 11:09 AM, Matthew Johnson <matt...@anandabits.com> wrote:
>
>>
>> On Jan 3, 2018, at 12:02 PM, Dave DeLong <sw...@davedelong.com
>> <mailto:sw...@davedelong.com>> wrote:
>>
>>
>>
>>> On Jan 3, 2018, at 10:58 AM, Kevin Nattinger <sw...@nattinger.net
>>> <mailto:sw...@nattinger.net>> wrote:
>>>
>>>>>> [...]
>>>>>> 2️⃣ If the enum is NOT decorated with @frozen, then I, as an app
>>>>>> author, have to account for the possibility that the module may update
>>>>>> from underneath my app, and I have to handle an unknown case. This is
>>>>>> simple: the compiler should require me to add a “default:” case to my
>>>>>> switch statement. This warning is produced IFF: the enum is coming from
>>>>>> an external module, and the enum is not decorated with @frozen.
>>>>>
>>>>> This does not help people who need to write a switch statement over an
>>>>> enum vended by a module that ships with the OS keep their code up to date
>>>>> as the module adds new cases. I find the example of
>>>>> `SKPaymentTransactionState` provided by Brent Royal-Gordon here:
>>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html
>>>>>
>>>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039512.html>
>>>>> to be compelling. There are rare but legitimate reasons to switch over
>>>>> all known cases of a non-@frozen enum that ship with the OS. These use
>>>>> cases deserve proper language support. I think Jordan’s solution strikes
>>>>> a good balance.
>>>>
>>>> I disagree that more is needed. In the case of the transaction state, it
>>>> should not be marked as @moana, and so the compiler would force you to add
>>>> a “default” case to your switch statements. The switch statements would
>>>> still be exhaustive with all known cases (if you choose to handle all
>>>> known cases), but you’d still need a default case because there might be
>>>> new transaction states in the future.
>>>
>>> And then you don't get the compiler error/warning when you start compiling
>>> against the next OS update that changes the enum. That is an absolutely
>>> unacceptable loss of compile-time checks.
>>
>> Ah, that’s an excellent point! Thanks for pointing that out.
>>
>> In that case, I revise my proposal:
>>
>> 1️⃣ a @frozen/@tangled/@moana attribute for enums that’s only consulted on
>> externally-linked modules
>> 2️⃣ a “future case:” statement that’s only required on externally-linked,
>> non-@moana enums. That way, if the enum adds a new case in the future,
>> you’ll still get a switch warning about handling all the cases. And then if
>> you want, you could “fallthrough” from this to a “default” case, or
>> vice-versa, or have separate implementations.
>
> It sounds to me like the main thing you’re unhappy about is having to deal
> with unknown cases when you have a source dependency that you always build
> and ship with an app. I don’t think anyone is happy with that situation.
That’s definitely part of it. The other main part is that I’m hugely resistant
to adding extraneous syntax when a solution that’s simpler for users exists.
> Did you take a look at the sketch of a solution provided by John McCall?
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html
>
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171218/042333.html>
I’ve read that email several times and don’t understand how it relates.
Dave
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
