> On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Ok, I understand that (among all the other things going on that are clearly
> more important) revamping this is probably not the highest priority thing to
> do. That said, it would be really unfortunate to carry around these
> “suboptimal” APIs forever, particularly given how marginal they are (as in,
> not widely used). I’m sure that there are other examples beyond these that
> are similarly unfortunate.
>
> Given that, I have a meta question for you: have you considered an approach
> where you take the Swift standard library and split it into two conceptual
> pieces:
>
> 1) The "ABI stable” subset of the library that gets burned into the OS.
> 2) The “ABI unstable” subset, which gets statically linked into apps, just
> like the Swift 4 library used to?
>
> Given that “import Swift” is implicit anyway, you could just have the
> compiler implicitly import *both* of these modules.
>
>
> The point of doing this is that it gives you a very general and low friction
> way to handle compatibility gunk. In addition to putting obscure stuff like
> Mirror and “DictionaryLiteral” into this (without breaking source code!) you
> now get the ability to put the various deprecated forwarding functions in
> this module as well, avoiding them becoming part of the ABI.
>
> The nice thing about this is that only people who use these things would have
> to pay the cost, and you can directly message this by deprecating all the
> stuff in it. Think about it as an overlay for the Swift standard library :-)
Hi Chris,
Even if we split the APIs into two sets, with an “ABI unstable” subset, we are
still going to “carry round these ’suboptimal APIs’” because clients are using
them today and those APIs — without an active plan to remove them — *are* a
part of the Standard Library. We’ve past the point in Swift where we can just
rip them out (you said so yourself in a follow up email).
It feels to me that the main advantage of the overlay is a solution to remove
out pieces of the Standard Library that will be used in practice less, and thus
clients don’t “pay the cost” when they don’t use them. But I think we should
be honest about what that “cost” actually is, as these APIs aren’t going away
right now. These suboptimal APIs will stay around at least until better ones
are created, and even then some existing clients will want to rely on the
existing suboptimal APIs anyway even if others want to take advantage of newer,
better APIs and idioms.
The main cost I see here that we save by having an “overlay for the Standard
library" is code size. On macOS/iOS it is true that applications embed a copy
of the Standard Library within them and thus pay a real cost in the Standard
Library’s actually payload size in their own app. However, the only reason
that is necessary today is because we don’t have ABI stability. With ABI
stability, other options for shipping the Standard Library — such as shipping
it in the OS — become possible, and thus the burden of shouldering that “cost”
of code size shifts around. Then the tradeoffs of having an overlay for the
Standard Library are different. In a world with ABI stability, is it better to
have a Standard Library "overlay" that only some clients use, and embed within
their application bundle, than just eat that cost in the Standard Library to be
shared by potentially multiple clients installed on a system? I think it
really comes down to the numbers. In that case, are we really just talking
about Mirrors? I haven’t run the numbers here, but my intuition tells me we
are talking about a relatively small code size impact overall.
There’s also other potential performance implications from doing this split.
Being able to have the Standard Library be in the OS has potential major
implications on the startup time of Swift applications. Right now, with the
Swift overlay libraries being part of the application bundle, on macOS/iOS
there is a real startup time impact of having these libraries shipped in
applications this way. Obviously reducing these down to one overlay — and
overlay that hypothetically wouldn’t be used often — would be a major
improvement over what we have today. But this would also introduce a
performance cliff for some clients that wanted to use the parts of the Standard
Library that were deemed “ABI unstable”. If an app starts using one of the
APIs in this part of the Standard Library — and possibly through an
intermediary such as a Swift package — then the app silently starts using this
overlay and thus gets the startup time hit and other costs of using it. For
some clients that will seem like an obscure performance cliff. In all
fairness, “cliff” might be hyperbole here, but my point is that the tradeoffs
of costs here are not linear and make the performance programming model of
using Swift a little more complicated.
Can you elaborate a bit more on the specific “cost” factors you are using when
proposing to have a Standard Library overlay? I think that’s really important
to help calibrate the dialogue here. I suspect different participants on this
thread have different optics on what ABI stability allows and disallows, and I
suspect your concerns are about paying specific costs into terms of carrying
forward what could be perceived as historical baggage, and less about being
able to make changes in the future. Is that a correct interpretation?
Ted
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
