> On Aug 10, 2017, at 3:52 PM, David Hart via swift-evolution > <[email protected]> wrote: > > > > On 10 Aug 2017, at 22:36, Adrian Zubarev <[email protected] > <mailto:[email protected]>> wrote: > >> Okay I came to the conclusion that this won’t work that easily. Here is my >> reasoning why I think that way. If one assume for a second that one day we >> might have value sub typing - yes not now and not in the next Swift version, >> but hear me out please - we will come back and discuss the alignment of >> `open/public` for value types (including enums of course) > > Does value sub-typing really imply overriding? Because if that’s not the > case, we won’t need the open keyword to limit overriding.
It definitely does not in my opinion. Value sub typing is effectively a form of implicit conversion that is guaranteed to succeed in producing a value of a different type (typically with a large set of inhabitants) that is logically equivalent. > >> which would allow us to create sub/super Types of an enum from module A in >> module B with `open` modifier, where on the other hand `public` would >> restrict sub/supertyping to the module where the enum is defined, very >> similar to classes. Here is the tricky part now. If we’d add a `closed` >> modifier which implies `public` then we end up with a hole that cannot be >> filled at that point of time, because we would only be able to declare a >> public-but-open and a public-but-closed enum. However we still would need be >> able to create an open-but-open enum (lhs open is the constraints for sub >> typing, rhs open is the constraint that we talk about in this thread). >> Therefore to support open-but-open version we would require a special >> keyword. >> >> I want to modify your main idea into: >> >> (Potentially possible in the future) >> - open-but-finite enum - or simply: open finite enum >> - open-but-infinite enum - or simply: open enum >> >> (Version that we could make possible in Swift 5) >> - public-but-finite enum - or simply: public finite enum >> - public-but-infinite enum - or simply: public enum >> >> >> Am 10. August 2017 um 22:00:40, David Hart ([email protected] >> <mailto:[email protected]>) schrieb: >> >>> >>> >>> On 10 Aug 2017, at 19:19, Jordan Rose <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> >>>>> On Aug 9, 2017, at 22:46, David Hart <[email protected] >>>>> <mailto:[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. >>> >>> Correct. Thanks for the clarification! But you still agree with the >>> argument, right? Convenience for same module enums (exhaustive by default), >>> safety for clients of the module (not-exhaustive when public from outside >>> the module), with the option to be explicit? And what do you think of the >>> idea of having the « exhaustiveness » modifier imply public, like open does? >>> >>>> Jordan >>>> > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
