Jordan Rose just posted the following on Swift-Evolution, in reference to the new Library Evolution Support in Swift (“Resilience”) document. The RFC requests comment feedback only and will not go through the Swift Evolution proposal process.

Hi, swift-evolution. We’ve been making references for a while to “resilience” as a cornerstone of the Swift 3.0 work, the collection of features that allows a library to evolve over time while maintaining binary compatibility. Among other things, this is necessary if we want to stop bundling the Swift standard library with any app that uses Swift, a noted complaint from iOS developers. 🙂

If you’re wondering what this is all about, take a look at the prologue for the design document:

One of Swift’s primary design goals is to allow efficient execution of code without sacrificing load-time abstraction of implementation.

Abstraction of implementation means that code correctly written against a published interface will correctly function when the underlying implementation changes to anything which still satisfies the original interface. There are many potential reasons to provide this sort of abstraction. Apple’s primary interest is in making it easy and painless for our internal and external developers to improve the ecosystem of Apple products by creating good and secure programs and libraries; subtle deployment problems and/or unnecessary dependencies on the behavior of our implementations would work against these goals.

Our current design in Swift is to provide opt-out load-time abstraction of implementation for all language features. Alone, this would either incur unacceptable cost or force widespread opting-out of abstraction. We intend to mitigate this primarily by designing the language and its implementation to minimize unnecessary and unintended abstraction:

• Avoiding unnecessary language guarantees and taking advantage of that flexibility to limit load-time costs.
• Within the domain that defines an entity, all the details of its implementation are available.
• When entities are not exposed outside their defining module, their implementation is not constrained.
• By default, entities are not exposed outside their defining modules. This is independently desirable to reduce accidental API surface area, but happens to also interact well with the performance design.

This last point is a specific case of a general tenet of Swift: the default behavior is safe. Where possible, choices made when an entity is first published should not limit its evolution in the future.