[swift-corelibs-dev] Looking at corelibs-foundation

Tony Parker anthony.parker at apple.com
Fri May 13 18:39:49 CDT 2016


> On May 13, 2016, at 4:13 PM, David Hart <david at hartbit.com> wrote:
> 
> Hi Tony,
> 
> I’m a bit confused by your answer. I am aware that some Objective-C Foundation and swift-corelibs-foundation classes share a common implementation through CF. My questions were really about the place of swift-corelibs-foundation on OS X and iOS. Can you help me understand?
> 
> What did you mean by "Technically, swift-corelibs-foundation is only part of the distribution on Linux.”?

On Darwin we will use the system framework. It is (clearly) far more mature than the swift-corelibs-foundation implementation.

Over time it’s not clear how the two will evolve, but we want them to evolve together from an API point of view at least.

> Will swift-corelibs-foundation be part of the canonical Swift distribution on OS X and iOS once Swift 3 is released?

No. Only on Linux or other non-Darwin platforms.

> What is the name of the swift-corelibs-foundation module on OS X and iOS? SwiftFoundation?

SwiftFoundation, and it is named this way specifically to avoid conflict with the system Foundation.

> What is the name of the swift-corelibs-foundation module on Linux? Foundation?

Foundation

> If those are different, isn’t there an incentive for having the same moule name on all platforms?
> 
> David.
> 

The system Foundation.framework on Darwin and swift-corelibs-foundation on Linux are both called “Foundation”.

Hope that clears this up.

- Tony


>> On 14 May 2016, at 00:44, Tony Parker <anthony.parker at apple.com <mailto:anthony.parker at apple.com>> wrote:
>> 
>> Hi David,
>> 
>> Much of the implementation is indeed shared (via the CoreFoundation C code, and the stuff it uses like ICU and libdispatch). Some of it is a reimplementation of the same API, but in Swift.
>> 
>> If you write code targeting the Foundation API, then you simply ‘import Foundation’. The idea here is that the implementation abstracts away the platform differences including the implementation itself.
>> 
>> - Tony
>> 
>>> On May 13, 2016, at 3:34 PM, David Hart <david at hartbit.com <mailto:david at hartbit.com>> wrote:
>>> 
>>> After looking into it, I guess it would be available, but under the SwiftFoundation module. Correct? I guess that decision was made so that Swift apps in production built on Foundation don’t break when recompiled under Swift 3? Is it worth converging the names of the module so its the same on all platforms? Isn’t it bad if portable code was doomed to have #if os() for all Foundation imports? If we do rename it, do we rename it to SwiftFoundation on Linux or do we rename it to Foundation on OS X (which would require renaming the Objective-C Foundation to something else and write a migration)?
>>> 
>>>> On 14 May 2016, at 00:19, David Hart via swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>> wrote:
>>>> 
>>>> 
>>>>> On 13 May 2016, at 21:50, Tony Parker <anthony.parker at apple.com <mailto:anthony.parker at apple.com>> wrote:
>>>>> 
>>>>> Technically, swift-corelibs-foundation is only part of the distribution on Linux. On Darwin platforms, we use a combination of the overlay (stdlib/public/SDK/Foundation directory in the Swift project) and the Foundation.framework that ships on the OS.
>>>> 
>>>> I’m confused about swift-corelibs-foundation only being part of the Linux distribution. Are you saying that when Swift 3.0 ships, import Foundation on OS X and iOS will still import the Objective-C framework? If yes, I’m very surprised, and I think many people will be. One of the goals of swift-corelibs-foundation (README) says:
>>>> 
>>>> 	• Provide a level of OS independence, to enhance portability.
>>>> 
>>>> How can it be portable if different platforms don’t share the same underlying core libraries?
>>>> 
>>>> David.
>>>> 
>>>> _______________________________________________
>>>> swift-corelibs-dev mailing list
>>>> swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160513/9eb0cf79/attachment.html>


More information about the swift-corelibs-dev mailing list