> On Aug 9, 2017, at 22:46, David Hart <[email protected]> wrote: > > >> On 10 Aug 2017, at 02:42, Jordan Rose <[email protected] >> <mailto:[email protected]>> wrote: >> >> :-) As you've all noted, there are some conflicting concerns for the default: >> >> - Source compatibility: the existing behavior for an unannotated enum is >> "closed". >> - Intuition: if you show someone an enum without an explicit annotation, >> they'll probably expect they can switch over it. (I'm going to say this is >> why Zach calls it a "sensible default".) >> - Consistency: switches on an enum in the same module can always be >> exhaustive, so having it be different across modules is a bit annoying. (But >> 'public' already acts like this.) >> >> vs. >> >> - Library evolution: the default should promise less, so that you have the >> opportunity to change it. >> - Flexibility: you can emulate an exhaustive switch with a non-exhaustive >> switch using fatalError, but not the other way around. >> >> All of this is why I suggested it be an explicit annotation in either >> direction, but Matthew brought up the "keyword soup" problem—if you have to >> write (say) "public finite enum" and "public infinite enum", but would never >> write "private finite enum" or "private infinite enum", something is >> redundant here. Still, I'm uncomfortable with the default case being the one >> that constrains library authors, so at least for binary frameworks (those >> compiled "with resilience") I would want that to be explicit. That brings us >> to one more concern: how different should binary frameworks be from source >> frameworks? > > In terms of intuition and consistency, I think we should really try to learn > from the simplicity of public/open: > > * When internal, classes are sub-classable by default for convenience, but > can be closed with the final keyword > * When public, classes are closed to sub-classing for safety, but can be > opened up with the open keyword (which implies public). > > If we try to mirror this behaviour (the keywords are just suggestions, not > important): > > * When internal, enums are exhaustive by default for convenience, but can be > opened-up with the partial keyword > * When public, enums are non-exhaustive by default for safety, but can be > made exhaustive with the exhaustive keyword (which implies public).
This is not a correct understanding of the internal/public distinction for classes, though. From inside a module, a public-but-not-open class is still subclassable, and similarly a public-but-not-"closed" enum will still be exhaustively switched. You don't have to worry about your own module changing out from under you. Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
