On Dec 31, 2015, at 2:54 PM, Erica Sadun via swift-evolution <[email protected]> wrote: > Under what criteria should we propose moving items into the standard library > and out from the standard library into Swift Foundation? Or will these things > eventually merge and become one grand unified module sometime in the distant > future?
Hi Erica, I don’t see any specific reason to merge the stdlib and Foundation together - it seems like Foundation depending on the swift stdlib is proper layering. Lets look at the mission of both of these libraries: For the Swift standard library, we want it to stay focused on the lowest-level “language support” primitives that includes things like Int, Array, Dictionary, OptionSet and the stuff they depend on (sequences etc). Even though they are implemented in the stdlib, I consider to be part of the the language. While we may elect to allow some minor scope creep, this will be carefully scrutinized and needs to be strongly justified. For Foundation, there may be differing short-term and long-term answers here. In the short-term, the corelibs projects have a very specific focus, which is to enable cross-platform Swift development by making common Foundation APIs available on other platforms. This is a pretty huge project, so it is important that we keep focused on making this happen, even though folks have the natural inclination to do “new” things as well. In this short term, I see SwiftPM as a great solution to avoid having to cram “everything interesting” into the standard library or Foundation. Once SwiftPM is ready, there should be very little downside to something being a package hosted on github or elsewhere. In the longer term, we’ll have to see what happens, and make a decision that makes sense given the direction the project takes. We may decide to start adding new functionality to Foundation that doesn’t exist on Apple platforms yet (with the understanding that they will adopt it as well). We may decide to “standardize” new corelibs from existing popular packages, if they are outside of the scope of Foundation (totally random example: perhaps a web templating framework). Putting something into the standard Swift distribution (instead of it being an independent package) comes with pros and cons. On the positive side, we want an official Swift release (e.g. "Swift 3.0”) to provide a consistent set of APIs out of the box that are guaranteed to be there. Getting your cool thing into the Swift distro guarantees that it will be available everywhere. On the downside, this is a bad way to go for rapidly evolving APIs in multiple ways: first, Swift has relatively infrequent updates (e.g. twice a year at current cadence) so it will take a long time to get changes out. Second, *changing* an API included in the Swift distribution will be comparatively hard. Instead of bumping the major version number of a package, it will have to go through a (TBD) lengthy deprecation process that will likely span multiple years. In any case, we’ll figure it out as we go. We don’t have all the answers, and we’re learning too. -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
