[swift-evolution] Enums and Source Compatibility

[Jordan Rose]

(responses to both Jon and Goffredo's most recent point inline)

> On Sep 28, 2017, at 16:15, Goffredo Marocchi <panajev at gmail.com> wrote:
> 
> Agreed, I am not seeing this change doing so much good because maybe it could prevent issues Library writers or developers updating libraries without checking things... not trying to be rude and/or non empathetic, but exhaustive enums never struck me as a bad thing and the reasons why they could be bad very quickly leads one to think “maybe you should not have been switching on enums there...”.

I suspect this is correct! Which makes non-exhaustive enums a way to communicate that this is probably not a good enum to switch exhaustively on. (Since switch statements can be used for other pattern-matching purposes in Swift, taking the F# route of disallowing matching cases altogether seems unnecessary.)

> On 28 Sep 2017, at 23:57, Jon Shier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> 	Actually, since proper dependency management for Apple platforms has existed outside of Apple for years now, this likely wouldn’t affect me at all, as long as the libraries I was using properly followed semantic versioning. I could keep using the compatible version of the libraries for however long I needed before moving to the new version and updating my code to exhaustively check for the new values. So please don’t make this change thinking you’ll be helping non-Apple framework providers here. Aside from actual binary compatibility I’m not sure there’s a compatibility case to be made here. 

From the semantic versioning point of view, non-exhaustive enums allow you to add a new case while changing only the minor version number and not the major version number. That is certainly an extra feature for non-Apple framework providers; whether or not it's a sufficiently useful one to justify the increased language complexity is, well, part of your evaluation of the proposal.

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170929/264df951/attachment.html>