[swift-evolution] A case for postponing ABI stability

[Greg Parker]

> On Jan 26, 2017, at 2:15 PM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jan 26, 2017, at 13:02, Rick Mann via swift-evolution <swift-evolution at 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'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.
>> 
>> 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.
> 
> On a scale of "trivial" to "impossible", how difficult would it be to have a mechanism for telling the compiler how to translate between major versions of the ABI/stdlib? Could we ship app/libs with a small "shim" library for backwards compatibility, if we had to? I mean it wouldn't be ideal, but if it's possible, "works" is better than either "doesn't work" or "painted into a corner", isn't it?
> 
> (In any case, this seems like a last resort... I bring it up not as a "proper" solution, but as a possible "emergency" way out, if we realize in 2-3 years that we locked some things down too soon.)

Depends on the differences between versions. Some changes are plausible to patch retroactively, but for most changes it is next to impossible. 

In general each ABI detail is locked down because there are compiled instructions that depend on it. To a close approximation existing compiled instructions cannot be changed. (Compiled instructions are hard to analyze. Compiled instructions are hard to rearrange without throwing off things like code<->code and code<->data offsets. Compiled instructions are often part of the OS or codesigned.) 


-- 
Greg Parker     gparker at apple.com     Runtime Wrangler