Yes, I see your point, and that’s something I didn’t consider. If we allowed extending enums, this would then clearly indicate that “final” means something in the present as well - you cannot add cases.
This opens up the can of worms of extending enums, but I think it’s a fair point if we ever want to consider it that then “final" really would make the most sense. > On 12 Aug 2017, at 8:28 am, Jordan Rose <jordan_r...@apple.com> wrote: > > "final"'s on my list of possible names! But it's not quite the same as > 'final' for classes: "closed" only talks about what might change in the > future, while 'final'-on-a-class also states something about the class in the > present: it has no subclasses now as well as not gaining any new ones in the > future. Still, it could be closed enough that it ends up being the best bet. > > Jordan > > >> On Aug 10, 2017, at 22:23, Rod Brown <rodney.bro...@icloud.com >> <mailto:rodney.bro...@icloud.com>> wrote: >> >> Hi all, >> >> I thought I’d chime in with my own 2c… >> >> I’d probably prefer something more like “final” and vs non-final. It’s the >> concept we’re dancing around - can you add something to extend it? >> >> In which case, final would allow exhaustive use, and non-final would require >> handling the default case. Currently all Swift API would convert as “final”, >> and all imported Obj-C API (with perhaps exceptions) would import as is and >> require a default handling case. This negates the open vs public issue. But >> it does also mean that it would become a manual issue inside the module to >> mark the API as final to allow exhaustive switches, unless we say >> “exhaustive switches allowed on internal/fileprivate/private types”. >> >> Unsure how this plays into the web of things, though… >> >> Thanks, >> >> Rod >> >> >> >>> On 11 Aug 2017, at 9:41 am, Jordan Rose via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> >>>> On Aug 10, 2017, at 13:00, David Hart <da...@hartbit.com >>>> <mailto:da...@hartbit.com>> wrote: >>>> >>>> >>>> >>>> On 10 Aug 2017, at 19:19, Jordan Rose <jordan_r...@apple.com >>>> <mailto:jordan_r...@apple.com>> wrote: >>>> >>>>> >>>>> >>>>>> On Aug 9, 2017, at 22:46, David Hart <da...@hartbit.com >>>>>> <mailto:da...@hartbit.com>> wrote: >>>>>> >>>>>> >>>>>>> On 10 Aug 2017, at 02:42, Jordan Rose <jordan_r...@apple.com >>>>>>> <mailto:jordan_r...@apple.com>> 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? >>> >>> That's the "library evolution" criterion above, yes. But the behavior of >>> enums inside the module doesn't need to affect what we do across modules. >>> >>>> And what do you think of the idea of having the « exhaustiveness » >>>> modifier imply public, like open does? >>> >>> I'm a little less sure about that. It does help with the keyword soup >>> problem, but it's also not as obviously about access as "open" was, and >>> "open" can also appear where other access modifiers can appear (on methods, >>> properties, and subscripts). >>> >>> Jordan >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
