[swift-evolution] A case for postponing ABI stability

[John McCall]

> On Jan 27, 2017, at 11:09 AM, David Scrève via swift-evolution <swift-evolution at swift.org> wrote:
>>> On Jan 27, 2017, at 2:57 AM, Charlie Monroe via swift-evolution<swift-evolution at swift.org(mailto:swift-evolution at swift.org)>wrote:
> 
>>> 
>> That's right. If the OS frameworks use Swift then either (1) you have to clone the framework stack for each Swift version, or (2) you have only one copy of the frameworks but frameworks and apps can't share their Swift objects or publish Swift API.
>> 
>> The framework structure that Apple inherited from NeXT supports framework versioning, but *no frameworks use it*. It doesn't scale.
>> 
>> (NeXT used framework versioning a few times, back when the entire OS only had a handful of frameworks. Today's AppKit and Foundation are version C. libSystem is version B. That's about it.)
> 
> 	I completely agree with ABI stability goal…I only have a fear regarding some postponed evolutions requests especially Abstract Classes. Would it be still possible ?

Abstract classes do not require anything special in terms of runtime support.  The ABI for an abstract class is basically the same as the ABI for a class except that you don't need to emit anything that would only be used for creating an instance of that class as the most-derived class.  We'd probably want to reserve a bit in the metadata to say "this class is abstract" just for reflection purposes, but even that can be done retroactively.

John.