Please note that, as proposed, enums are always treated as exhaustive *within the same module*. A new user writing MyFirstEnum is likely using it within the same module, and will thus get exhaustive behavior with no extra keywords required.
-BJ > On Sep 17, 2017, at 3:20 PM, Christopher Kornher via swift-evolution > <swift-evolution@swift.org> wrote: > > >>> On Sep 17, 2017, at 6:33 AM, Rod Brown via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>>> On 17 Sep 2017, at 4:35 am, Christopher Kornher <ckorn...@me.com> wrote: >>>> >>>> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> If a library writer can’t remember to declare non-exhaustive enums as >>>> such, they probably will forget many more important aspects of creating a >>>> library. They probably should not be writing libraries. Arguments like >>>> this make sense on the surface, but creating libraries involves hundreds >>>> or thousands of decisions. I wish you luck in making that process idiot >>>> proof. A library linter could easily warn that exposed enums are >>>> exhaustive. The exhaustive keyword should be optional to make the decision >>>> obvious and suppress warnings. Complicating the user experience in a vain >>>> attempt to make “expert" coding safer is misguided. >> >> I think the same logic goes both ways: If a library author can’t remember to >> declare exhaustive enums as such, they will probably forget many more >> important aspects of creating a library. >> >> The problem here is fundamental: Exhaustive is a guarantee. A guarantee >> should require action. Non-Exhaustive guarantees nothing. It makes you >> safer. That is all. > > 1) Exhaustive enums are inherently better: they allow a developer to know > that they have covered all possible cases by not using a default. > 2) This proposal forces developers to add a keyword to get this behavior in > their apps, which is common to all other languages with enums that I have > used. This proposal breaks the model common to all (?) current > implementations of enums. > > >> >>> >>> This may be a little harsh, but there don’t seem to be many advocates for >>> novice and “ordinary” application developers on this list. That is not >>> unexpected given the number of extremely knowledgeable compiler and library >>> developers on this list (for whom I have the highest respect). I believe >>> that there are more creative (and probably more difficult to build) >>> possible solutions to some of the tough problems in Swift’s future. In that >>> spirit, see below. >> >> I personally am an “ordinary” application developer. >> >> I think the issue here is that everyone is seeing Swift as *they* intend to >> use it. For App Devs, exhaustive switches are nice, which means they really >> are fighting tooth and nail to keep them. I understand that. But I’m also >> trying to keep my mind open for “what happens to an app I compiled in iOS 15 >> that I compiled for iOS 11?” And this gives me pause. I can’t ask Apple or >> any other library author to be completely knowledgable about every case in >> the future, and to audit every line of code and manually give non-exhaustive. >> >> Why do people want “exhaustive” to be the default? >> Because we like things as they are. > > No, because it makes sense to make common things easy and uncommon things > possible. > >> Because we like not having to consider edge cases. Because we want to >> imagine that will give framework developers the control to make our lives >> difficult because they’ll just be lazy and make our lives hard by not >> annotating. And this certainly is a concern. But I think a larger concern is >> breaking apps left, right and centre, or not being able to extend frameworks >> because an earlier developer on a project made an oversight. > > This happens all the time: Apple deprecates APIs and asked developers to use > new ones. If a library writer does not run (the as-yet hypothetical ) library > lint, not participate in thorough code reviews,…, they can simply create a > new non-exhaustive enum and deprecate the old one. Yes, there will be some > redundant function calls for a while, but again, similar things happen, even > in APIs like Apple’s, that (one hopes, at least) are thoroughly reviewed. It > is not the end of the world to deprecate and migrate APIs. You may remember > garbage collected Objective-C, the change that “viewWillAppear” suddenly was > not called when it used to be in iOS. We all survived the elimination of GC > and moving our view initialization code. Libraries and developers can survive > mistakes and improvements. > > ABI stability does not require foolproof, immutable, ABIs. In essence, it is > just a guarantee that the build system won’t require rebuilds if library > source code stays the same, or is added to, not that applications will never > have to be rebuilt in the real world where breaking changes are often > required. Adding ABI stability when enums change (in limited ways, don’t > forget, removing a case is a breaking change) is a good addition, but it does > not rise to the level of requiring degradation of the experience for > beginners, IMO. > > >> Its in everyone’s best interest to think before we put handcuffs on, no >> matter how painful that is. Even if that means you make apps where you just >> write “default: fatalError(“I don’t handle unreachable defaults”)" >> >> And lets be clear: Swift isn’t an app development language. It also isn’t a >> framework development language. It’s a multipurpose language designed to >> Take Over The World™. This means we need to think holistically about what is >> better for everyone. Not just ourselves. > > That includes being easy to learn and understand. Enums are exhaustive in > other languages and should be exhaustive by default in Swift. No extra > keywords should be required to create “MyFirstEnum” that behaves in a > sensible way. The documentation that describes why you need to write a > ‘default’ clause or 'exhaustive' when you have all the possible cases written > down should be interesting. May I suggest: “You see, if you write a library > (don’t worry about what that means right now) you don’t have to worry about > being not very good at it. If and when you write one, it will be a tiny bit > easier, so write this meaningless clause or the magical keyword — your > choice.” > >> >>> >>>> >>>> >>>>> >>>>> If you declare it is exhaustive and it was an oversight, and then realise >>>>> after the fact that you are wrong, you have to open it up. This will >>>>> break third party apps. It will be disallowed by the ABI compatibility >>>>> requirements. >>>>> >>>>> If you declare it isn’t exhaustive due to an oversight (or perhaps you’re >>>>> just not sure yet), and then realise after the fact it is exhaustive, you >>>>> can close it up. This will not break third party apps. It will also be >>>>> allowed for ABI compatibility. >>>>> >>>>> This benefits everyone. Make library owners choose a guarantee, rather >>>>> than be defaulted into it. Much like they have to declare choose to >>>>> declare “final” on a class: you can’t retroactively reneg that promise: >>>>> it will break everyone who assumed it to be the case! >>>> >>>> It does not benefit the creation of 90+% of enums. It is one more arcane >>>> rule for the vast majority of developers. >>> >>> The Swift compiler could offer a “strict enum exhaustiveness” (bikeshedding >>> not included) switch that could be enabled by default for library targets >>> and disabled by default for “application” targets. The switch would make >>> not explicitly specifying exhaustiveness an error or warning when enabled. >>> Perhaps this could be combined with other options that would tailor the >>> development experience for library/application developers. This would help >>> avoid “zero-sum” choices between benefitting library or application >>> developers in the future. >> >> The Swift team have fundamentally opposed such pushes for “compiler modes” >> for a long time. I don’t expect they will embrace them now, nor do I think >> they should just to avoid us devs having to write the occasional “default” >> clause. This is, to be clear, a relatively rare case. > > It is probably a good choice, but there are potential upsides. Oh, course, > this could easily lead to a library dialect and an application dialect of > Swift. That is already the de-facto state of affairs for many languages, > including Swift. Would formalizing the difference make of “taking over the > world” more attainable or just create a mess? A "library switch" could be > horribly abused, and should only be used as a last resort. Ideally, it would > only generate warnings in library mode. > > >> >>> >>> Xcode and the SPM should be able to distinguish between the target types >>> and generate the proper defaults. I do not believe that this is too >>> mysterious for developers. There would be learning step for developers >>> wiring their first library, but that is not necessarily a bad thing since >>> creating a reusable library requires a different mindset than creating an >>> application. >>> >>> >>>> >>>>> >>>>>> >>>>>> Exhaustive and open by default with keywords to close things down if the >>>>>> framework author wants them. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On 16 Sep 2017, at 09:55, David Hart via swift-evolution >>>>>>> <swift-evolution@swift.org> wrote: >>>>>>> >>>>>>> I’m still very much bothered by having 2 new keywords. I would really >>>>>>> prefer the following plan: >>>>>>> >>>>>>> Exhaustive by default in Swift 4 >>>>>>> No new keyword in Swift 4 to change that behaviour >>>>>>> Non-exhaustive by default outside the module in Swift 5 >>>>>>> exhaustive keyword to change the default behaviour >>>>>>> >>>>>>> Like that, we don’t need nonexhaustive. >>>>>>> >>>>>>> Thoughts? >>>>>>> David. >>>>>>> >>>>>>>> On 13 Sep 2017, at 21:16, Jordan Rose via swift-evolution >>>>>>>> <swift-evolution@swift.org> wrote: >>>>>>>> >>>>>>>> Proposal updated, same URL: >>>>>>>> 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! >>>>>>>> Jordan >>>>>>>> >>>>>>>> >>>>>>>>> On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution >>>>>>>>> <swift-evolution@swift.org> wrote: >>>>>>>>> >>>>>>>>> Sorry, I got distracted by other tasks! Both the discussion here and >>>>>>>>> within Apple has moved towards making "non-exhaustive" the default, >>>>>>>>> which, to be honest, I too think is the best design. I'll update the >>>>>>>>> proposal today to reflect that, though I still want to keep both the >>>>>>>>> "nonexhaustive" and "exhaustive" keywords for Swift 4 compatibility >>>>>>>>> for now (or whatever we end up naming them). The compatibility design >>>>>>>>> is a little less ambitious than Brent's; as currently proposed, Swift >>>>>>>>> 4 mode continues to default to 'exhaustive' all the time, even in the >>>>>>>>> actual Swift 5 release. >>>>>>>>> >>>>>>>>> I still want to respond to Brent's points directly, but I think you >>>>>>>>> and Vladimir have done a good job discussing them already. I'll send >>>>>>>>> out the updated proposal tomorrow, after I have a little more time to >>>>>>>>> think about #invalid. >>>>>>>>> >>>>>>>>> Thanks for putting time into this! >>>>>>>>> Jordan >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Sep 9, 2017, at 17:34, Rod Brown <rodney.bro...@icloud.com> wrote: >>>>>>>>>> >>>>>>>>>> Jordan, >>>>>>>>>> >>>>>>>>>> Do you have any other thoughts about the ongoing discussion here, >>>>>>>>>> especially regarding Chris’ comments? As you’re the one pushing this >>>>>>>>>> forward, I’d really like to know what your thoughts are regarding >>>>>>>>>> this? >>>>>>>>>> >>>>>>>>>> - Rod >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
