[swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Jordan Rose]

Removing cases just isn’t allowed. They can be deprecated, but actually removing one is a breaking change. With a Swift enum the app will actually fail to launch with a dynamic linking error.

Jordan


> On Jan 10, 2018, at 21:27, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> 
> It is a two way street though. An app compiled against an old framework might pass a deleted enum case back to the new framework that has been changed under it. 
> 
> Just as the app has to guard against new cases the framework has to guard against old cases!
> 
> Both ends need an unknown case. 
> 
> -- Howard. 
> 
>> On 10 Jan 2018, at 5:40 pm, Jordan Rose <jordan_rose at apple.com> wrote:
>> 
>> Remember, the goal here is to support both binary and source compatibility. An existing app might be using the enum case that you're trying to remove, but there's no chance that an existing app is using an enum case that you're trying to add.
>> 
>> Jordan
>> 
>> 
>>> On Jan 10, 2018, at 16:34, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> If an enum isn’t final; then what’s the difference in deleting as opposed to adding?
>>> 
>>> -- Howard. 
>>> 
>>>> On 10 Jan 2018, at 4:13 pm, Jean-Daniel <mailing at xenonium.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution <swift-evolution at swift.org> a écrit :
>>>>> 
>>>>> Two points:
>>>>> 
>>>>> 1. I like Chris’s suggestion of #unknown and in particular that it is distinct from default. 
>>>>> 
>>>>> 2. All the discussion is about a framework adding a case, what about when a framework deletes a case?
>>>> 
>>>> This is a binary breaking change (just like removing an existing function or method).
>>>> 
>>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>