As described in e.g. https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#what-does-abi-stability-enable <https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#what-does-abi-stability-enable>, it primarily enables OSes to ship with a copy of the standard library and runtime, rather than every app having to bundle their own copy. It’s also a crucial piece of supporting 3rd party frameworks. There are also more subtle benefits such as the de-coupling of developer tools that work with Swift binaries (e.g. debuggers and profilers). Some of the tasks towards stability are performance improvements we want to do anyways.
> On Jan 25, 2017, at 1:36 PM, Rick Mann via swift-evolution > <[email protected]> wrote: > > I'm also late to the thread (and the ABI stability discussion in general). Is > there a reference online that describes the reason for desiring ABI > stability? I mean, I get, generally, why we need it. But I'd like to see the > arguments for why we need it *now*, before certain other things are in place. > Not saying the reasons for the urgency aren't valid, I just don't know what > they are. > > Thanks! > >> On Jan 25, 2017, at 08:44 , Freak Show via swift-evolution >> <[email protected]> wrote: >> >> This is both great to hear (ivar introspection available) and a little >> disappointing (method level not). Basically, I would hope for at least >> enough to allow implementation of KVC - which would require the ability to >> find and invoke methods by name. >> >> >> >>> On Jan 24, 2017, at 14:16, Joe Groff <[email protected]> wrote: >>> >>> a lot of the information you'd need for many dynamic features is already >>> there, and planned to be stabilized as part of the ABI. We already emit >>> reflection data that describes the physical layouts of types, and once >>> those formats are stabilized, building a library that interprets the >>> metadata is additive (and could conceivably be done by a third party >>> independent of the standard library). There may not be metadata for >>> individual methods yet >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > -- > Rick Mann > [email protected] > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
