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

[Rod Brown]

Please see response inline

- Rod

> On 2 Jan 2016, at 9:13 AM, 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.) 
> 

I find this a very good point and points to something interesting with Swift Foundation.

Is it more important to maintain design closely similar to Objective-C foundation, or to push for a more "swift" design philosophy that may indeed push away from Objective C foundation?

We are essentially outlining some of the foundational (no pun intended) elements of Swift, and a clean, coherent design makes sense. That said, I suspect branching away from Objective-C Foundation may create confusion for developers who write both for Apple Platforms and for servers - "Am I using Swift Foundation, or Objective-C Foundation?"

I think some clarifications on direction would be helpful here before I consider diving in and helping with Swift Foundation (which does interest me a lot!)

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160102/6ae8502e/attachment.html>