> On Jan 27, 2017, at 11:09 AM, David Scrève via swift-evolution > <swift-evolution@swift.org> wrote: >>> On Jan 27, 2017, at 2:57 AM, Charlie Monroe via >>> swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@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. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
