Proposed Foundation URL Improvements

Charles Hu:

URL is one of the most common types used by Foundation for File IO as well as network-related tasks. The goal of this proposal is to improve the ergonomics of URL by introducing some convenience methods and renaming some verbose/confusing ones. Specifically, we proposed to:

• Introduce a new StaticString initializer
• Refine the existing “file path” initializers
• Refine appendingPathComponent and friends
• Introduce common directories as static URL properties

[…]

We propose to add all “get URL” style methods from FileManager to URL as static methods. This allows the call site to use Swift’s powerful static member lookup to get the URLs to predefined directories instead of always needing to spell out FileManager.default. We also propose to add a few more static directory URLs that correspond to FileManager.SearchPathDirectory.

Aside from being verbose, I’ve never liked the FileManager.urls(for:in:) API because it returns an array that could potentially be empty. So I have to either risk a crash or check for that case and either report an error or substitute my own fallback. The proposed new API simply offers properties (which can’t throw) for the basic directories that I care about.

Karl:

Unfortunately, URL.appendingPathComponent just forwards to NSURL.appendingPathComponent, which makes blocking calls to the filesystem. So does URL(fileURLWithPath:) (here).

But I do agree that a URL type should be a pure model type, and that the results of URL manipulation should never depend on the state of the filesystem.

Thomas Clement:

This has always bothered me as well, because what if the path doesn’t actually exist on disk at this point? Or what if the path isn’t readable from the current process permissions? Or what if the items on disk are later replaced by others (e.g. file could turn into a directory).

Karl:

It sounds weird - like, surely everybody would have noticed already if URLs didn’t conform to Comparable - but it’s true! It doesn’t conform!

Alejandro Martinez:

It’s probably out of scope for this but my biggest issue with URL is its strict parsing. The amount of times a feature breaks because suddenly we get a url with spaces that URL refuses to parse it’s not small.

Everyone who deals with lots of URLs seems to have their own code to try to “fix up” invalid URLs that they get from user input or other external sources. It probably makes sense for URL to be strict by default, but it would be nice to have an option for more leniency, e.g. along the lines of what Safari does if you type in something that doesn’t follow RFC 1738.

Previously:

• Swift FilePath Syntactic Operations
• The Weirdness of NSURL’s isDirectory Flag
• URL Path Retrieval Cheat Sheet
• NSURL Path Handling

Cocoa iOS Mac Swift Programming Language URL

2 Comments RSS · Twitter

---

---

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ