-
Notifications
You must be signed in to change notification settings - Fork 129
Description
It's quite awkward to work on an application where both System.FilePath and SystemPackage.FilePath are floating around.
I love that this package is available, but as things stand, I'm having to add the following code to my libraries to facilitate type conversions:
#if canImport(System)
import System
import SystemPackage
@available(macOS 11, iOS 14, tvOS 14, watchOS 7, *)
extension System.FilePath {
/// Creates a `FilePath` (from the platform's `System` framework) from a `FilePath` (from the `swift-system` package).
///
public init(_ packageFilePath: SystemPackage.FilePath) {
self = packageFilePath.withCString { .init(cString: $0) }
}
}
@available(macOS 11, iOS 14, tvOS 14, watchOS 7, *)
extension SystemPackage.FilePath {
/// Creates a `FilePath` (from the `swift-system` package) from a `FilePath` (from the platform's `System` framework).
///
public init(_ sdkFilePath: System.FilePath) {
self = sdkFilePath.withCString { .init(cString: $0) }
}
}
#endifBut this isn't really the kind of code I feel my library should be responsible for. It's really none of my business to bridge between these 2 libraries. Would it be acceptable to add these to the package distribution?
I understand that the compiler may provide better tools for dealing with this, and if/when that happens, these functions could be deprecated and removed at the next SemVer-major release. Until that time, adding these functions (and perhaps others for FileDescriptor) would make using the package distribution much more ergonomic.