[API Review] FilePath Syntactic APIs

Related Projects System
59

Version 2 of this proposal can be found here. This thread was tremendously helpful and I want to thank everyone who took the time to review and comment on this API.

Changes:

  • Spin off FilePath.Root from Component
    • Provides a much clearer separation of API
    • Allows for many corner cases to be handled by the type system
    • FilePath.Root can in the future be a namespace for Windows root analysis
  • FilePath.ComponentView is now also a RangeReplaceableCollection
    • Standard Swift algorithms operate over homogeneous components of a path
  • FilePath.Component has a Kind enum, illustrating mutual exclusivity
  • relativePath was renamed removingRoot()
    • Consistent with other "removing" APIs
    • More precise on Windows (where a rooted path can be relative)
  • Rename basename/dirname to lastComponent and removingLastComponent()
    • Include @available(unavailable, renamed:) entries for discoverability
    • removeLast is now removeLastComponent (it doesn't remove a root)
  • append overhaul:
    • append now only takes Components, so there are no roots involved
    • append overload taking a String for common stringy treatment of paths
      • Ignores a leading separator if needed
      • Will be preferred for string literal arguments
    • push is introduced for the common cd-like semantics
      • aka join in Python, push in Rust, Combine in C#, append in C++17
  • ing variants of everything introduced for expression chaining
    • __consuming and __owned annotations added to make these efficient
  • Add lexicallyResolving(), a secure-ish append over untrusted subpaths
  • Add CTypes empy enum to serve as a namespace for C typealiases
    • PlatformChar and PlatformUnicodeEncoding are nested inside CTypes
    • Allows us to add more C types without polluting global namespace
  • Added deferred/future-work section about working with paths from another platform
8 Likes