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

[Dave Abrahams]

> On Jan 1, 2016, at 2:13 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Thanks Chris.  I want to figure out what the guiding principles are before I blow any further proposal-capital. This gives me a good place to start chewing on some thoughts.  In particular, I'm considering two scenarios.
> 
> First, are things that seem unnaturally split between both places, such as "joinWithSeparator" (stdlib, seq type) and "componentsSeparatedByString" (fnd, NSString). The latter super non-Swifty but could easily evolve to be componentsSeparatedBySequence and rangeOfSequence. (We had some nifty attempts at this last night on #swift-lang in terms of trying to do this with reasonable speed.) 

It’s still a Swift 3 goal of the standard library to "make String awesome” (which entails many things from better usability to broader functionality). IMO an awesome string has to be in the base layer of the language, and can’t require pulling in Foundation.  We’re not ready to start having this conversation in detail on swift-evolution yet, but I’m very much looking forward to discussing it with the community.

> Second, is how to push on what to add -- particularly for integrating proposals from the rich libraries of other languages. I'm interpreting what you wrote as that a standard library should be as flexible and widely applicable as possible while being implemented with the fewest possible moving parts ("stay focused on the lowest-level “language support” primitives") 
> 
> This is counter to having to cram everything interesting into the standard library or Foundation but opens the possibility of creating standard Ruby-esque, Rust-esque, Haskell-esque, etc. packages, right? I'm going to take a wild guess that these latter items would have to be self organizing and fall outside the umbrella of Swift and Swift-Evolution. For this bit, I'm going to defer to Kevin, etc for figuring out what would be awesome to add in.
> 
> -- E
> 
> 
>> On Jan 1, 2016, at 1:46 PM, Chris Lattner <clattner at apple.com> 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

-Dave