[swift-evolution] Enums and Source Compatibility

[Goffredo Marocchi]

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...”.


Sent from my iPhone

> On 28 Sep 2017, at 23:57, Jon Shier via swift-evolution <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. 
> 
> 
> 
> Jon
> 
>> On Sep 28, 2017, at 4:52 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> 
>>> On Sep 27, 2017, at 16:48, Jessie Serrino <jessie at serrino.co> wrote:
>>> 
>>> Hi there,
>>> 
>>> Just want to circle back on a few things.
>>> 
>>> You mentioned that library vendors communicate deprecation notices, but this is very prone to error. If someone misses the notice that a library puts out to communicate that the contracts of the enum have changed, this could break existing functionality they have already built. 
>>> 
>>> You also mention that it's really hard for a library developer to predict how their enum will change, but it's even harder for a library developer to fully predict how a different user will use their library. As a developer, I don't want to have to look at the release notes to find out when a library has changed its contracts-- I want it to alert me in the most aggressive way possible to make sure that major changes to the library have been captured in my own code.
>> 
>> Hi, Jessie. This is a reasonable view, but in our experience it's not the most important thing. What we've seen is that people want their code to keep building after an update, and in particular they want their dependencies to keep building. That is, if your app depends on HomeworkKit, and HomeworkKit adds a new case, you probably want to know about it. But if someone's app depends on CoreAcademia, and CoreAcademia depends on HomeworkKit, they're probably just going to be upset if CoreAcademia no longer builds. In practice, that person/team stops updating HomeworkKit until there's a CoreAcademia update available, or possibly stops working on their app altogether, to avoid editing someone else's library.
>> 
>> (Again, this becomes even more critical if HomeworkKit is a part of the OS, in which case there's not even a choice whether or not to update. But I can see that being handled separately.)
>> 
>> I'm not completely against having an additional notion of an "otherwise-exhaustive" switch, as discussed under "Preserve exhaustiveness diagnostics for non-exhaustive enums". But that's a feature we can add later, whereas differentiating exhaustive and non-exhaustive enums is something that must be done before Swift libraries can be part of the OS.
>> 
>> Jordan
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> 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/20170929/cef43965/attachment.html>