Please see response inline - Rod
> On 2 Jan 2016, at 9:13 AM, Erica Sadun via swift-evolution > <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
