[swift-evolution] Winding down the Swift 3 release
L. Mihalkovic
laurent.mihalkovic at gmail.com
Tue May 24 15:28:45 CDT 2016
> On May 24, 2016, at 7:56 PM, Chris Lattner <clattner at apple.com> wrote:
>
>
>> On May 24, 2016, at 12:00 AM, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
>>
>>
>>
>>>> On May 24, 2016, at 1:21 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>>>>
>>>> On May 23, 2016, at 2:17 AM, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
>>>> The collection model, API guidelines and standard library are actually irrelevant to the ABI. The standard library API and the Swift ABI are distinct orthogonal concepts.
>>>
>>> I’m not sure what you’re saying. If you change the API shipped by the standard library, it obviously breaks anything that links to it.
>>>
>>> The whole point of ABI stability is to not break apps built with old versions of Swift compiler / standard library.
>
>> 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.
> -Chris
More information about the swift-evolution
mailing list