[swift-evolution] A case for postponing ABI stability
xenadu at gmail.com
Sun Jan 29 01:18:35 CST 2017
> On Jan 27, 2017, at 2:08 PM, Freak Show via swift-evolution <swift-evolution at swift.org> wrote:
> Maybe so - but IB M
> solved this very problem along with release to release binary compatibility for C++ and a number of other languages twenty years ago with the System Object Model (SOM).
Yeah and Microsoft’s COM is a reasonable approach (and Apple ships a version of it used for plugin loading).
Unfortunately you end up with IFrob, IFrob2, IFrob3, IFrob4, IFrobEx, IFrobEx2. You also introduce a hard boundary that makes passing “native” types across the boundary impossible. Everything must fit inside the set of types described by COM. For Swift any scheme boils down to “use a lowest-common-denominator and give up all of Swift’s advanced type system features”.
Believe me, there are parts of the Simulator stack where I would like to use Swift but without ABI stability it just isn’t possible. If there were a plausible alternative I’d happily take it. There isn’t.
> I'm not arguing for its adoption per se - but good ideas are always worth stealing and there was some solid engineering in there.
> Sent from the road
>> On Jan 27, 2017, at 09:19, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
>> I wouldn't expect that I can mix language and framework versions freely.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution