Ah yes, my eye skipped that alternative for some reason! Sorry. I’d be concerned that avoiding a default is a fix for a compatibility problem, not a language design decision. If we look back in 5 years and say “why do we need to keep writing nonexhaustive everywhere?”, we’ll have to say “there were compatibility problems with Swift 4-to-5”. That reeks of a language I just want to walk away from. Yuk.
In this case, either way, we’ll need to do some work. So why not let the migrator migrate this code correctly to “exhaustive”, which is the current behaviour? I think a decision where either way we break source compatibility should be done in the interest of language design, not in the short term interest of avoiding confusion. But that’s just my 2c. Thanks, Rod > On 6 Sep 2017, at 10:36 am, Jordan Rose <[email protected]> wrote: > > It's in the "Alternatives Considered" section. :-) That was my desired design > when we started, but feedback convinced me that the break from Swift 4 mode > would be too drastic. The same valid code would have a different meaning > whether you were writing Swift 4 or Swift 5. > > Jordan > > >> On Sep 5, 2017, at 17:30, Rod Brown <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Jordan, >> >> I’m not sure how much bearing on this my comment will have. >> >> Have you considered having only “exhaustive” as a keyword, and make the >> default non-exhaustive? It seems that “exhaustive" would be the rarer case, >> as it promises a lot more about compatibility (much like there is no such >> thing as “non-final”). Also, non exhaustive seems a massive mouthful despite >> it probably being the correct term. >> >> - Rod >> >>> On 6 Sep 2017, at 10:19 am, Jordan Rose <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I've taken everyone's feedback into consideration and written this up as a >>> proposal: >>> 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>. >>> The next step is working on an implementation, but if people have further >>> pre-review comments I'd be happy to hear them. >>> >>> Jordan >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
