Hi Jordan, Upon further reflection, I’m going to withdraw my concerns about the defaulting and I think it’s the right solution after all. This is due to several thoughts I had rolling it around my head:
1. In a private project, you would expect all cases to be exhaustive, as this is guaranteed by the compiler (no compatibility concerns). Exhaustive makes sense here, as it has always done in Swift code, and is why it was the behaviour since Swift 1. 2. When we make projects public, we already need to vet them for compatibility concerns with final etc. This should be part of the process of making them public. 3. It's source compatible with libraries, as mentioned in the proposal. I can imagine there will still be a tonne of work needed for apps compiling against Apple’s Obj-C SDKs when Swift 5 comes out due to this change. Almost all enums will become nonexhaustive, but this will then show up in documentation changes, header updates etc, and as you’ve mentioned, it will avoid confusion. Sorry! I think I just needed some time to roll it around my head a bit haha - Rod > On 6 Sep 2017, at 10:47 am, Rod Brown via swift-evolution > <[email protected]> wrote: > > 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] >> <mailto:[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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
