[swift-evolution] A case for postponing ABI stability

[David Sweeris]

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

- Dave Sweeris