You may remember that when we originally pitched splitting Foundation, it was noted that libxml2 was a dependency it was possibly worth splitting out. I have landed patches to produce the proposed FoundationXML module; similar to FoundationNetworking, end users will need to import this module explicitly to use XML parsing facilities.
For the full details on this and other changes, check out the swift-corelibs-foundation release notes. The relevant portions on the split are also in this post below:
Dependency management release notes
On Darwin, the OS provides prepackaged dependency libraries that allow Foundation to offer a range of disparate functionalities without the need for a developer to fine-tune their dependency usage. Applications that use swift-corelibs-foundation do not have access to this functionality, and thus have to contend with managing additional system dependencies on top of what the Swift runtime and standard library already requires. This hinders packaging Swift applications that port or use Foundation in constrained environments where these dependencies are an issue.
To aid in porting and dependency management, starting in Swift 5.1, some functionality has been moved from Foundation to other related modules. Foundation vends three modules:
FoundationFoundationNetworkingFoundationXML
On Linux, the Foundation module now only has the same set of dependencies as the Swift standard library itself, rather than requiring linking the libcurl and libxml2 libraries (and their indirect dependencies). The other modules will require additional linking.
The following types, and related functionality, are now only offered if you import the FoundationNetworking module:
CachedURLResponseHTTPCookieHTTPCookieStorageHTTPURLResponseURLResponseURLSessionURLSessionConfigurationURLSessionDataTaskURLSessionDownloadTaskURLSessionStreamTaskURLSessionTaskURLSessionUploadTaskURLAuthenticationChallengeURLCacheURLCredentialURLCredentialStorageURLProtectionSpaceURLProtocol
Using this module will cause you to link the libcurl library and its dependencies. Note that the URL structure and the NSURL type are still offered by the Foundation module, and that, with one exception mentioned below, the full range of functionality related to these types is available without additional imports.
The following types, and related functionality, are now only offered if you import the FoundationXML module:
XMLDTDXMLDTDNodeXMLDocumentXMLElementXMLNodeXMLParser
Using this module will cause you to link the libxml2 library and its dependencies. Note that property list functionality is available using the Foundation without additional imports, even if they are serialized in the xml1 format. Only direct use of these types requires importing the FoundationXML module.
The recommended way to import these modules in your source file is:
#if canImport(FoundationNetworking)
import FoundationNetworking
#endif
#if canImport(FoundationXML)
import FoundationXML
#endif
This allows source that runs on Darwin and on previous versions of Swift to transition to Swift 5.1 correctly.
There are two consequences of this new organization that may affect your code:
-
The module-qualified name for the classes mentioned above has changed. For example, the
URLSessionclass's module-qualified name wasFoundation.URLSessionin Swift 5.0 and earlier, andFoundationNetworking.URLSessionin Swift 5.1. This may affect your use ofNSClassFromString,import classâŚstatements and module-name disambiguation in existing source code. See the 'Objective-C Runtime Simulation' section in the release notes for more information. -
FoundationprovidesData(contentsOf:),String(contentsOf:âŚ),Dictionary(contentsOf:âŚ)and other initializers on model classes that takeURLarguments. These continue to work with no further dependencies for URLs that have thefilescheme (i.e., for which.isFileURLreturnstrue). If you used other URL schemes, these methods would previously cause a download to occur, blocking the current thread until the download finished. If you require this functionality to work in Swift 5.1, your application must link or dynamically load theFoundationNetworkingmodule, or the process will stop with an error message to this effect. Please avoid this usage of the methods. These methods block a thread in your application while networking occurs, which may cause performance degradation and unexpected threading issues if used in concert with theDispatchmodule or from the callbacks of aURLSessionTask. Instead, where possible, please migrate to using aURLSessiondirectly.