Skip to content

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

@karwa

Description

@karwa

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions