Since an absolute URI is still relative to root, I feel like there should be a way to finagle relative and absolute URIs into a single type.
> On Aug 22, 2017, at 2:37 PM, Taylor Swift via swift-evolution > <swift-evolution@swift.org> wrote: > > So are you saying we need three distinct “URI” types for local-absolute, > local-relative, and remote? That’s a lot of API surface to support. > >> On Tue, Aug 22, 2017 at 12:24 PM, Dave DeLong <del...@apple.com> wrote: >> I completely agree. URL packs a lot of punch, but IMO it’s the wrong >> abstraction for file system paths. >> >> I maintain an app that deals a lot with file system paths, and using URL has >> always felt cumbersome, but String is the absolute wrong type to use. Lately >> as I’ve been working on it, I’ve been experimenting with a concrete “Path” >> type, similar to PathKit (https://github.com/kylef/PathKit/). Working in >> terms of AbsolutePath and RelativePath (what I’ve been calling things) has >> been extremely refreshing, because it allows me to better articulate the >> kind of data I’m dealing with. URL doesn’t handle pure-relative paths very >> well, and it’s always a bit of a mystery how resilient I need to be about >> checking .isFileURL or whatever. All the extra properties (port, user, >> password, host) feel hugely unnecessary as well. >> >> Dave >> >>> On Aug 20, 2017, at 11:23 PM, Félix Cloutier via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> I'm not convinced that URLs are the appropriate abstraction for a file >>> system path. For the record, I'm not a fan of existing Foundation methods >>> that create objects from an URL. There is a useful and fundamental >>> difference between a local path and a remote path, and conflating the two >>> has been a security pain point in many languages and frameworks that allow >>> it. Examples include remote file inclusion in PHP and malicious doctypes in >>> XML. Windows also had its share of issues with UNC paths. >>> >>> Even when loading an arbitrary URL looks innocuous, many de-anonymizing >>> hacks work by causing a program to access an URL controlled by an attacker >>> to make it disclose the user's IP address or some other identifier. >>> >>> IMO, this justifies that there should be separate types to handle local and >>> remote resources, so that at least developers have to be explicit about >>> allowing remote resources. This makes a new URL type less necessary towards >>> supporting file I/O. >>> >>> Félix >>> >>>> Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution >>>> <swift-evolution@swift.org> a écrit : >>>> >>>> Okay so a few days ago there was a discussion about getting pure swift >>>> file system support into Foundation or another core library, and in my >>>> opinion, doing this requires a total overhaul of the `URL` type (which is >>>> currently little more than a wrapper for NSURL), so I’ve just started a >>>> pure Swift URL library project at <https://github.com/kelvin13/url>. >>>> >>>> The library’s parsing and validation core (~1K loc pure swift) is already >>>> in place and functional; the goal is to eventually support all of the >>>> Foundation URL functionality. >>>> >>>> The new `URL` type is implemented as a value type with utf8 storage backed >>>> by an array buffer. The URLs are just 56 bytes long each, so they should >>>> be able to fit into cache lines. (NSURL by comparison is over 128 bytes in >>>> size; it’s only saved by the fact that the thing is passed as a reference >>>> type.) >>>> >>>> As I said, this is still really early on and not a mature library at all >>>> but everyone is invited to observe, provide feedback, or contribute! >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
