[swift-evolution] Enums and Source Compatibility

[Rod Brown]

> On 6 Sep 2017, at 4:35 pm, David Hart <david at hartbit.com> wrote:
> 
> Hi Jordan,
> 
> I like this new direction. But I have Rod’s inverse question: have you considered only having the nonexhaustive keyword? Similar to how non-final doesn't exist because its opposite is the default behaviour. That would also free us from searching for a good pair of keywords and only find one good keyword (extensible, expandable, …) which doesn’t contain a negative.

I was thinking the same. If exhaustive is the default, and how Swift has always worked, then why have that keyword anyway? I like extensible/expandable but I worry the connotation some might come away with that you could add cases externally, which is not in scope.

> 
> David.
> 
>> On 6 Sep 2017, at 02:36, Jordan Rose <jordan_rose at apple.com <mailto: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/7164f1aa/attachment.html>