<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Please see response inline</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">- Rod</div><div><br>On 2 Jan 2016, at 9:13 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><span>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.</span><br><span></span><br><span>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.) </span><br><span></span><br></blockquote><div><br></div><div>I find this a very good point and points to something interesting with Swift Foundation.</div><div><br></div><div>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?</div><div><br></div><div>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?"</div><div><br></div><div>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 <i>lot</i>!)</div><br><blockquote type="cite"><span>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") </span><br><span></span><br><span>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.</span><br><span></span><br><span>-- E</span></blockquote></body></html>