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@swift.org> wrote: > > > >> On Sep 27, 2017, at 16:48, Jessie Serrino <jes...@serrino.co >> <mailto:jes...@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
