> On 29. Sep 2017, at 00:24, Dave DeLong via swift-evolution > <swift-evolution@swift.org> wrote: > > 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 >
I don’t see how it’s impractical. Quite a lot about how the library should be optimally compiled and used depends on what you plan to do with it. If it’s going to be installed somewhere private and you can guarantee clients will always have the latest version, you can assume all data types are final, @_fixed_layout, @exhaustive, whatever (essentially in-module). An example of that would be a library embedded inside an iOS app bundle. If it’s going to be installed somewhere public and expose some API (like Apple’s frameworks), then you’re going to have to think about binary compatibility. That also means that in-app libraries are optimised as much as they can be, and that resilience-related changes on the declaration side can be limited to the limited set of Swift developers who truly have to care about that. - Karl >> On Sep 28, 2017, at 4:18 PM, Dave DeLong via swift-evolution >> <swift-evolution@swift.org <mailto: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 <mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
