[swift-evolution] Enums and Source Compatibility

[Rod Brown]

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 <jordan_rose at apple.com> 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 <rodney.brown6 at icloud.com <mailto:rodney.brown6 at icloud.com>> 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 <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170906/3eaee95e/attachment.html>