[swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Ted Kremenek]

> On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution <swift-evolution at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180111/1684633c/attachment.html>