> On Jan 11, 2018, at 12:01 AM, Ted Kremenek <kreme...@apple.com> wrote: >> 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).
Who is “we” and how do you define carry? I think you’re saying that they will remain part of the swift project (in the “SwiftDeprecated” module) for effectively ever. If so, I agree, and that’s the point. The point is that the code can continue to exist and service the few people who need it (and will become even fewer over the years) without causing *harm* to the Swift ecosystem over the near or long term. That’s the feature. > 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. Yes, exactly. > 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. I’m not sure what you mean. I’m talking about two things specifically: 1) APIs that are already deprecated and have replacements. The deprecated version goes in this library, avoid carrying them around forever. 2) APIs that are used by extremely narrow audiences, which were added without much consideration and that have not been redesigned since Swift 1. Mirror’s are an example of this. I’m arguing that these should be moved to this SwiftDeprecated module - but not actually deprecated until a replacement exists. I don’t see how this is bad for anyone, and I think this provides a significant process improvement compared to your current approach, which forces you to lock down APIs now without careful consideration just because they are not “important enough”. > The main cost I see here that we save by having an “overlay for the Standard > library" is code size. I don’t understand this point. > 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. This comment doesn’t make a lot of sense to me, perhaps we’re talking across each other. The point of the design that I’m advocating for is that all apps (that deploy to iOS-next or later) get a immediate improvement from abi stability: the vast majority of the standard library is not put into their app bundle. Further, the vastly most common apps - those that are not using mirrors or deprecated APIs, also do not include the SwiftDeprecated module. Only the tiny minority of apps that do use these APIs would have a copy of SwiftDeprecated in their app dylib, but they have a path to fix that, and they would still see a huge improvement from the bulk of the standard library being out of their app bundle. > > There’s also other potential performance implications from doing this split. This doesn’t make sense to me. We’re not talking about taking comonly used apis here. Mirrors are not performance sensitive at all, and neither are deprecated wrappers of renamed APIs. > Being able to have the Standard Library be in the OS has potential major > implications on the startup time of Swift applications. It is great for app developers to have an incentive to stop using deprecated APIs! :-) > Can you elaborate a bit more on the specific “cost” factors you are using > when proposing to have a Standard Library overlay? I think it is possible that you’re reading too much into the “overlay" word here, so ignore that. The design I’m proposing is really simple: 1. The vast majority of the standard library goes into the OS. This includes all the string, array, and other stuff people use. 2. The deprecated wrappers and obscure APIs go into a new module, and that module doesn’t go into the OS. Only people that use it pay to cost. This isn’t particularly complicated, if give you new ways to manage the process of stdlib ABI stability, and I don’t see the downside. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
