[swift-evolution] Philosophy question: Foundation and Standard Library

[Trent Nadeau]

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.

On Fri, Jan 1, 2016 at 3:46 PM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> On Dec 31, 2015, at 2:54 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160101/deb50cd5/attachment.html>