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 <[email protected]> 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 <[email protected]> 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 >>> <[email protected]> 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 <[email protected]> wrote: >>>> >>>> >>>> >>>>> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution >>>>> <[email protected]> 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 >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
