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_r...@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@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 <mail...@xenonium.com> wrote: >>> >>> >>> >>>> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution >>>> <swift-evolution@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
