> On Jan 27, 2017, at 2:08 PM, Freak Show via swift-evolution > <swift-evolution@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@swift.org> wrote: >> >> I wouldn't expect that I can mix language and framework versions freely. > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
