This exists, but it's imperfect: it's possible that an app and its embedded frameworks are not all linked against the same version of the SDK, and then the system framework has to go with whatever the app does. (It's more important to behave consistently within a process.)
It's not impossible to design something like this for Swift and even for third-party frameworks, but that particular limitation is inherent. It also doesn't always make sense to try to emulate the old behavior—in the first system that gains support for DVDs, it's not really worth pretending that they're CDs or floppy disks. I contend that non-exhaustive enums are a fact of life for OS frameworks, and still a good thing for open source frameworks. Jordan > On Oct 2, 2017, at 10:29, Wallacy via swift-evolution > <swift-evolution@swift.org> wrote: > > @Slava > > If my understanding is correct. If I compile my application with the x.y.z > version of a Apple System Framework (like Cocoa). And this framework is > updated, several calls from my application to the "new" framework version > x.z.a behave like in the x.y.z version for compatibility issues right? I see > this being mentioned in the Cocoa documentations sometimes. > > Is possible to do this here? > > I usually don't care about non-exhaustive enums. We avoid this even in > languages which do not enforce us (using external tools sometimes). But i can > understand the "need" in some projects. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
