[swift-evolution] Enums and Source Compatibility

[Christopher Kornher]

> On Sep 16, 2017, at 8:41 AM, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> On 16 Sep 2017, at 7:22 pm, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> I am still unsure why we are choosing again a default that protects library writers more than library users where it is reasonable to expect the former to have better mastery of the language, to architect a library with some scalability, and ability to add unit test to cover themselves from issues than the latter.
> 
> Because protecting library owners protects library users.

If a library writer can’t remember to declare non-exhaustive enums as such, they probably will forget many more important aspects of creating a library. They probably should not be writing libraries. Arguments like this make sense on the surface, but creating libraries involves hundreds or thousands of decisions. I wish you luck in making that process idiot proof. A library linter could easily warn that exposed enums are exhaustive. The exhaustive keyword should be optional to make the decision obvious and suppress warnings. Complicating the user experience in a vain attempt to make “expert" coding safer is misguided.


> 
> If you declare it is exhaustive and it was an oversight, and then realise after the fact that you are wrong, you have to open it up. This will break third party apps. It will be disallowed by the ABI compatibility requirements.
> 
> If you declare it isn’t exhaustive due to an oversight (or perhaps you’re just not sure yet), and then realise after the fact it is exhaustive, you can close it up. This will not break third party apps. It will also be allowed for ABI compatibility.
> 
> This benefits everyone. Make library owners choose a guarantee, rather than be defaulted into it. Much like they have to declare choose to declare “final” on a class: you can’t retroactively reneg that promise: it will break everyone who assumed it to be the case!

It does not benefit the creation of 90+% of enums. It is one more arcane rule for the vast majority of developers.

> 
>> 
>> Exhaustive and open by default with keywords to close things down if the framework author wants them.
>> 
>> Sent from my iPhone
>> 
>> On 16 Sep 2017, at 09:55, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> Proposal updated, same URL: 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>.
>>>> 
>>>> Thanks again for all the feedback so far, everyone!
>>>> Jordan
>>>> 
>>>> 
>>>>> On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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.brown6 at icloud.com <mailto:rodney.brown6 at 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 at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170916/8aa7f98b/attachment.html>