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