> On Oct 2, 2017, at 11:29 AM, 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?
Unfortunately, no. That behavior is manually implemented by the framework authors. Dave > > 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. > > > Em sáb, 30 de set de 2017 às 21:00, Slava Pestov via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> escreveu: >> On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I don’t see how it’s impractical. Quite a lot about how the library should >> be optimally compiled and used depends on what you plan to do with it. If >> it’s going to be installed somewhere private and you can guarantee clients >> will always have the latest version, you can assume all data types are >> final, @_fixed_layout, @exhaustive, whatever (essentially in-module). An >> example of that would be a library embedded inside an iOS app bundle. If >> it’s going to be installed somewhere public and expose some API (like >> Apple’s frameworks), then you’re going to have to think about binary >> compatibility. >> >> That also means that in-app libraries are optimised as much as they can be, >> and that resilience-related changes on the declaration side can be limited >> to the limited set of Swift developers who truly have to care about that. > > We do plan on exposing an -enable-resilience flag which basically does what > you describe. When a library is built without -enable-resilience, all types > are assumed to be fixed layout, etc. However, we don’t want language flags to > change language semantics, so exhaustive/nonexhaustive still make sense even > when building without resilience, I think. When you switch over a > non-exhaustive enum that came from a library built without > -enable-resilience, the compiler can still use the most efficient possible > access pattern and assume that no new cases will be introduced, but the type > checker would still require a default case to be present. The optimizer can > then basically strip out the default case as dead code. > > Slava > >> >> - Karl > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
