[swift-evolution] A case for postponing ABI stability

[Russ Bishop]

> 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.

Russ

> 
> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution