I don’t think this use-case should be overlooked, especially as we approach the stable ABI.
If a library can change out from underneath you (because you’re not embedding it yourself) then it is inherently unsafe to assume that any enum in that library is exhaustive. The developer may think that it is for version 1, but the development of version 2 may reveal cases that were not originally considered. Apple, which has just about as much experience as anyone in the world with shipping frameworks, has a strong commitment to binary compatibility, but even they get it wrong sometimes. IMO, the proper way to deal with “exhaustive” enums vs not is: - any enum in any framework you ship is exhaustive. (Rationale: since you’re embedding it with your product, you have explicit control over handling all its cases) - any enum in any framework you link is non-exhaustive. (Rationale: since the framework is not part of your product, it could change without you knowing, which means you must handle unexpected values via a default case) Dave > On Sep 21, 2017, at 12:48 PM, Jordan Rose <jordan_r...@apple.com> wrote: > > >> On Sep 20, 2017, at 16:15, Dave DeLong <sw...@davedelong.com> wrote: >> >> Hi Jordan, >> >> One thing I’m still not clear on exhaustive vs non-exhaustive… >> >> What will stop a developer from releasing an exhaustive enum in version 1 of >> their library, and then adding a new case in version 2? >> >> With ABI stability and libraries getting updated independently of apps, this >> can be a major problem. > > We have some ideas to deal with this, though nothing promised yet: > > - A checker that can compare APIs across library versions, using swiftmodule > files or similar. > - Encoding the layout of a type in a symbol name. We could have clients link > against this symbol so that they’d fail to launch if it changes, or just > check the list of exported symbols to make sure it didn’t change. > > The feature’s useful even if we have to do it by hand for now, but it’s a > good question to ask. I’ll mention this in the proposal under “Future > directions”. > > Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
