> On 18 Sep 2017, at 19:20, Jordan Rose <jordan_r...@apple.com> wrote: > > That's pretty much the same as this proposal except you don't have the new > keyword. I'm not sure why that really makes a difference, since they're > obviously paired, and it would limit existing libraries from declaring > exhaustive enums until they've moved entirely to Swift 5 mode. I think the > current proposal makes sense as is.
The difference is that it reduces the keyword soup and removes a keyword that will be the default behavior enums have in Swift 5. If we follow the same reasoning, why don’t we have nonfinal, @nonescaping, @nonDiscardableResult? Is it really worth adding a keyword only to support libraries while they transition to Swift 5? > Jordan > > >> On Sep 16, 2017, at 01:55, David Hart <da...@hartbit.com> 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
