> On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution > <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 https://lists.swift.org/mailman/listinfo/swift-evolution
