[swift-evolution] [swift-corelibs-dev] Proposal: Swift Open Source Project and Foundation replacements

[David Hart]

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.parker at 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 <david at 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.parker at apple.com> wrote:
>>>> 
>>>> Hi Jacob,
>>>> 
>>>> On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch <jtbandes at gmail.com> wrote:
>>>> 
>>>>> On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner <clattner at 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 at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151204/ad1017a9/attachment-0001.html>