> On Sep 16, 2017, at 8:41 AM, Rod Brown via swift-evolution > <[email protected]> wrote: > > > On 16 Sep 2017, at 7:22 pm, Goffredo Marocchi via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> I am still unsure why we are choosing again a default that protects library >> writers more than library users where it is reasonable to expect the former >> to have better mastery of the language, to architect a library with some >> scalability, and ability to add unit test to cover themselves from issues >> than the latter. > > Because protecting library owners protects library users.
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. > > 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. > >> >> 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 >> <[email protected] <mailto:[email protected]>> 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 >>>> <[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! >>>> Jordan >>>> >>>> >>>>> On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>>>>> <mailto:[email protected]>> 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 >>>>> [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] <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] <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] <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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
