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@swift.org> wrote: > > >> On 13 May 2016, at 21:50, Tony Parker <anthony.par...@apple.com >> <mailto:anthony.par...@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@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
