The improvements to the Objective-C bridge in Swift 3 are definitely appreciated but are just cosmetics (they only affect naming). What about the fact that NSURL in your example, being an immutable type, would be better represented by a value type in Swift? Don't misunderstand me, I applaud the fact that corelibs exists, and understand that Foundation has a lot of great ideas, but I would have preferred seeing it exist as a community hobby project instead of an official Swift project and have the community instead concentrate on a core library that embraces value types, generics, protocols, etc...
> On 04 Dec 2015, at 00:14, Tony Parker <anthony.par...@apple.com> wrote: > > Hi David, > > Fundamentally, we believe that the Foundation library is part of Swift. We > also believe that it would be a mistake to throw out the many years of > experience that it brings with it. In areas where there are impedance > mismatches between the existing API and what feels “Swifty”, we can improve > the API of Foundation to make it as great to use there as it is in > Objective-C. The first step of that is our heavy involvement with the Swift 3 > naming guidelines here: > > https://swift.org/documentation/api-design-guidelines.html > > Hope this helps, > - Tony > >> On Dec 3, 2015, at 3:09 PM, David Hart <da...@hartbit.com> wrote: >> >> Hi Tony, >> >> Like Jacob, I would have preferred a completely original corelibs library >> that uses that clean sheet to be as bold in library design as the standard >> library is. Why would that direction go against the goal of begin "as >> standards compliant as possible”? it would just mean that Apple Platform >> developers would have the option of using the Objective-C bridge to talk to >> Objective-C Foundation or use the “swifter” corelibs. >> >> David. >> >>>> On 03 Dec 2015, at 23:33, Tony Parker <anthony.par...@apple.com> wrote: >>>> >>>> Hi Jacob, >>>> >>>> On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch <jtban...@gmail.com> wrote: >>>> >>>>> On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner <clatt...@apple.com> 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 >>>> swift-corelibs-dev@swift.org >>>> 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: >>> >>> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents_URIParser.c >>> >>> (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 >>> >>> >>> >>> _______________________________________________ >>> swift-corelibs-dev mailing list >>> swift-corelibs-dev@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
