Winding down the Swift 3 release

Chris_Lattner · May 24, 2016, 10:11pm

This is a nuanced topic. Jordan and John have started working on a document to describe our “resilience” design, a draft is available here:

github.com

apple/swift/blob/main/docs/LibraryEvolution.rst

:orphan:

.. default-role:: term
.. title:: Library Evolution Support in Swift ("Resilience")

.. note::

    This document uses some Sphinx-specific features which are not available on
    GitHub. For proper rendering, download and build the docs yourself.

Since Swift 5, ABI-stable platforms have supported `library evolution`_, the
ability to change a library without breaking source or binary compatibility.
This model is intended to serve library designers whose libraries will evolve
over time. Such libraries must be both `backwards-compatible`, meaning that
existing clients should continue to work even when the library is updated, and
`forwards-compatible`, meaning that future clients will be able run using the
current version of the library. In simple terms:

- Last year's apps should work with this year's library.
- Next year's apps should work with this year's library.

This file has been truncated. show original

-Chris

···

On May 24, 2016, at 1:28 PM, L. Mihalkovic <laurent.mihalkovic@gmail.com> wrote:

I regularly read see how stability is a high prioriy goal going forward. But what I have not found yet what the plan is going to be to achieve it without stiffling the standard library? Are there constructs, or rules is place/planned that map how changes of kind A versus B level changes will be keeping/breaking compatibility? (I have not finished all the docs)

Once ABI stability is established, functionality can only be added to the standard library, not removed or have a significant behavior change. For example, fundamentally changing the index model for collections would be impossible, but adding a new kind of collection would be fine.

Thank you for taking the time to reply.
I am interested in understanding how finer granularity changes like adding methods to protocols, or adding new conformance requirements to existing types will or not impact compatibility. For eg I read about the possibility of upcoming default implementations in protocol. Is that part of the long term binary compatibility plans, or unrelated? I do realize many answers are in the compiler dev-list (read most but not all), the docs and the source code (have yet to read what's loaded at runtime from the binary) but any pointers would be appreciated.
Thank you again.