> On Sep 27, 2017, at 16:48, Jessie Serrino <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
