On Jan 1, 2016, at 12:56 PM, Trent Nadeau <[email protected]> wrote: > Speaking of release cadence, do you think that Swift could transition to the > release train model (i.e., staged release, beta, and nightly) once source and > ABI compatibility are both established? That would allow a quicker cadence > and more testing of new library and language features. It's seems to be > working well with Rust so far, at least.
Anything is possible, we’re always open to good ideas. -Chris > > On Fri, Jan 1, 2016 at 3:46 PM, Chris Lattner via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > On Dec 31, 2015, at 2:54 PM, Erica Sadun via swift-evolution > <[email protected] <mailto:[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] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > -- > Trent Nadeau
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
