> On Sep 14, 2017, at 20:59, Chris Lattner <[email protected]> wrote: > > >> On Sep 13, 2017, at 12:17 PM, Jordan Rose via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> Proposal updated, same URL: >> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md >> >> <https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md>. >> >> Thanks again for all the feedback so far, everyone! > > Hi Jordan, > > I’d appreciate it if you could look at the comments I made upthread and > respond to them. Thanks.
Hi, Chris. Sorry for not responding directly – I assumed because your model was very close to this revised proposal, you wouldn't be expecting a direct response. At this point, I think the only discrepancy between your version and mine is that you'd use a shared annotation 'fragile' (or whatever) rather than an enum-specific annotation 'exhaustive' (or whatever). There are a few reasons why I didn't go with that: - Unlike the other possible "fragility attributes" described in the Library Evolution <http://jrose-apple.github.io/swift-library-evolution/> plan, 'exhaustive' changes the behavior of the type in a way that's visible to clients. Stating that a struct has a fixed set of stored properties, or that a function's definition can be inlined into a caller, acts purely as an optimization; it doesn't change what client source code can or cannot do with a type. - Because exhaustivity affects clients, it's something that is useful for libraries distributed as source* as well as those with binary-compatibility concerns. If such a library provides an exhaustive enum in its public API, adding a new case would be a source-breaking change and require a major version bump (if the library is using semantic versioning <http://semver.org/>). Therefore, just like open and non-open classes, it is beneficial to distinguish between the exhaustive and non-exhaustive situations even for libraries distributed as source. Such libraries should have no need for the other fragility attributes because we expect to be able to perform those optimizations by default. I really wish 'open' made sense here, because that's the closest analogous situation, but it just doesn't. So we need a separate annotation (although as mentioned in the proposal I'm okay with reusing 'final'). It does help now that `public enum` works without any further annotation; that's due to your feedback as well as pushes within Apple. Jordan * I'm saying "libraries distributed as source", but really this applies to any libraries that get packaged with the end product, usually an app. The real condition here is whether a client must be rebuilt to use a new version of the library, i.e. "libraries without binary compatibility concerns". These aren't officially supported by Apple today, but the model shouldn't leave them out.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
