I also realize that this may be an impractical approach to solving this problem, because it would require teaching the analyzer about built products, with knowledge of what’s going to be copied, etc etc.
So, the alternative view to this would be: - any enum that you are compiling is exhaustive - everything else is non-exhaustive Dave > On Sep 28, 2017, at 4:18 PM, Dave DeLong via swift-evolution > <swift-evolution@swift.org> wrote: > > 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 >> <mailto:jordan_r...@apple.com>> wrote: >> >> >>> On Sep 20, 2017, at 16:15, Dave DeLong <sw...@davedelong.com >>> <mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
