> On Jan 26, 2017, at 1:02 PM, Rick Mann via swift-evolution > <swift-evolution@swift.org> wrote: > > Thanks for that, that's helpful. > > My concern, of course, is the obvious one: that we'll have to compromise on > future functionality in order to not break ABI compatibility, or we'll have a > painful transition when we do break it. While today it's suboptimal to ship > copies of the runtime with each application, it's a working solution. >
I don’t disagree with your overall point, but I do want to emphasize that forcing apps to bundle the stdlib and runtime is more than just suboptimal. For many companies, increasing the OTA download size has real financial impact as it can affect whether new users are willing to download an app, as well as whether they will wait for it to download and install. That being said, I hope that many of the ABI stability tasks[2] also result in smaller binary sizes for applications. They should be prioritized highly no matter when stability happens. > I'd really like to make sure Swift can be fully introspective (soon), but I > don't know how easy it will be to add that after the ABI is locked down. > Maybe I'm just being alarmist. I'd also like to see the ability to replace > code at run time. > New runtime APIs are ABI-additive. It’s likely that much of Swift’s already extensive type metadata will be kept opaque[1] to allow the language to continue to grow and change, and new entries can be added. > If all that is already accommodated by the current ABI, then I'm satisfied. > But it seems like there's some concern about this, and I worry that locking > down the ABI too early will make those additions MUCH harder in the future. > Locking down the standard library API and (some) exposed implementation details is certainly a scary aspect of ABI stability. [1] https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#type-metadata <https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#type-metadata> (third paragraph) [2] https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#compact-manglings <https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#compact-manglings> and https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#suffix-differentiation <https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#suffix-differentiation> > Thanks! > >> On Jan 25, 2017, at 15:09 , Michael Ilseman <milse...@apple.com> wrote: >> >> As described in e.g. >> 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 >>> <swift-evolution@swift.org> 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 >>>> <swift-evolution@swift.org> 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 <jgr...@apple.com> 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 >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> -- >>> Rick Mann >>> rm...@latencyzero.com >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > > -- > Rick Mann > rm...@latencyzero.com > > > _______________________________________________ > 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
