On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch <address@hidden> wrote:On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner <address@hidden> wrote:
As others have surmised, the goal for the Swift Foundation project is to provide a pure-swift implementation (which reuses widely-available C libraries) of important Foundation APIs that do *not* depend on the Objective-C runtime. Reusing GNUstep, Cocotron, or even Apple’s existing Foundation implementation didn’t allow us to achieve those goals, so we didn’t go with those approaches.This is great, but is the goal also to exactly duplicate all the idiosyncrasies of the Obj-C Foundation?Quiz: what's the result of NSURL(string: "http://one/two;three/four")?.URLByAppendingPathComponent("five") ?If, as I would hope, corelibs-foundation is an opportunity to make simpler APIs that resolve some of these weirdnesses, then should the class names (NSURL, NSFileHandle, etc.) really be the same?_______________________________________________
swift-corelibs-dev mailing list
address@hidden
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
I think NSURL is actually a pretty great example of an API that we want to be the same on all platforms. There is quite a bit of logic backing it (along with something like NSURLComponents). Check out some of it here:
(and that CF code is reflected up into NSURLComponents)
It’s tricky stuff, and the goal is to get it as standards compliant as possible. If we use this implementation for all Swift clients then we can get a consistent answer everywhere - and even better, fix bugs everywhere at the same time.
So if you find some of the interface confusing (or wrong), then file a bug for us at bugs.swift.org. We can take this opportunity to try to make it better for everyone.
Thanks,
- Tony