Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add System.FilePath <-> SystemPackage.FilePath conversion? #60

Open
karwa opened this issue Aug 19, 2021 · 0 comments
Open

Add System.FilePath <-> SystemPackage.FilePath conversion? #60

karwa opened this issue Aug 19, 2021 · 0 comments

Comments

@karwa
Copy link

karwa commented Aug 19, 2021

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) }
    }
  }
#endif

But 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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant