> On Jan 3, 2018, at 12:02 PM, Dave DeLong <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.  Did you take 
a look at the sketch of a solution provided by John McCall?  
> Dave
>>> In those cases, your app could decide what to do, if that’s possible at 
>>> all. Maybe there’s other transaction information you could introspect to 
>>> determine if it succeeded or is still pending or whatever, and then your 
>>> app could respond as you see fit.
>>> Dave
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>

swift-evolution mailing list

Reply via email to