[swift-evolution] Philosophy question: Foundation and Standard Library
anthony.parker at apple.com
Mon Jan 4 18:59:56 CST 2016
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.
> On Jan 1, 2016, at 10:32 PM, Rod Brown via swift-evolution <swift-evolution at swift.org> 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 <clattner at apple.com> wrote:
>>>> On Jan 1, 2016, at 3:32 PM, Rod Brown <rodney.brown6 at icloud.com> 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.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution