> On Jan 26, 2017, at 13:02, 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'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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
