apple
Foundation additions
Should the open-source Swift System have a new module, with the same Foundation additions as in the closed-source Swift System?
// MARK: - Foundation Additions
import Foundation
// Available when Foundation is imported with System
@available(macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0, *)
extension FilePath {
/// Creates a file path from a URL
///
/// The result is nil if `url` doesn't refer to a local file.
public init?(_ url: URL)
}
// Available when Foundation is imported with System
@available(macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0, *)
extension URL {
/// Creates a URL from a file path by by copying and validating its UTF-8 contents.
///
/// This initializer does not try to repair ill-formed UTF-8 code unit
/// sequences. If any are found, the result of the initializer is `nil`.
///
public init?(_ path: FilePath)
/// Creates a URL from a file path by by copying and validating its UTF-8 contents.
///
/// This initializer does not try to repair ill-formed UTF-8 code unit
/// sequences. If any are found, the result of the initializer is `nil`.
///
public init?(_ path: FilePath, isDirectory: Bool)
}
@lorentey do you know what the story is with cross-import overlays, especially in a package build environment?
We can definitely have the code in System, but I'm not sure how the build system side of things would work out with SwiftPM. @abertelrud do you know how SPM handles cross-import modules?
One thing we could do is to put the combo overlay APIs into a separate build product that must be imported explicitly.
I think it would be better if these went the other way - i.e. in Foundation.
The reason is that the natural layering of these 2 libraries would have swift-system sit at the bottom, and for Foundation to depend on it and use it, and for swift-system not to depend on Foundation. For example, it would be fantastic if FS APIs such as FileManager would also accept a FilePath without requiring that it goes through String.
@karwa that's certainly how things are starting to shake out, at least for implementation details. I think it would be nice to formally establish this layering. Foundation will (likely) forever pull in the Darwin module though, so we'll still have the C APIs as well as System.
@Catfish-Man thoughts?
I think it would be better if these went the other way - i.e. in Foundation.
The reason is that the natural layering of these 2 libraries would have swift-system sit at the bottom, and for Foundation to depend on it and use it, and for swift-system not to depend on Foundation.
+1 on that, it's nice to be able to build server-side swift without pulling in Foundation at all (and swift-system is definitely useful for that context).
