Not that I need to say this, but I’ll chime in anyway with a big +1 to what Chris said. =)
Fortunately, the current code owners for swift-corelibs-foundation are the same people that work on Foundation for all of our other platforms. That means we’re in a great position to make Foundation great in Swift everywhere. As Chris said, we have a giant task of getting the fundamentals up and running without Objective-C, so that is our primary goal for Swift 3. However, we are interested in all kinds of improvements in the long term. Thanks, - Tony > On Jan 1, 2016, at 10:32 PM, Rod Brown via swift-evolution > <[email protected]> wrote: > > Brilliant. Makes sense and seems to be a best-of-both-worlds approach. > > - Rod > > On 2 Jan 2016, at 3:16 PM, Chris Lattner <[email protected]> wrote: > >>>> On Jan 1, 2016, at 3:32 PM, Rod Brown <[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? >> >> Our goal is to pull the two together, so that Foundation ultimately feels >> 100% Swift native. This is one major reason that we’re doing >> corelibs-foundation the way we are in the first place, to force the design >> discussions to happen. >> >> We plan to do this through a combination of improving how Swift imports >> Objective-C APIs (something that made a lot of progress in Swift 2, and >> should make at least some more progress in Swift 3) as well as by adding >> “more swifty” interfaces manually where it makes sense (e.g. through >> overlays). This is something you should discuss on a case by case basis >> with the corelibs folks, because there is no one blanket answer. >> >>> 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?” >> >> This would be a pretty big problem, defeating the goal of supporting >> cross-platform development with Swift. >> >> -Chris >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
