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
