If value-based generics become a thing, then you’ll be able to specify a URL type with URL<.file> which would pretty much solve this problem.
> On Aug 21, 2017, at 11:24 AM, Félix Cloutier via swift-evolution > <[email protected]> wrote: > > There's no question that there's a lot in common between file: URLs and other > URLs, but that hardly makes URLs better in the file: case. > > I saw the enum. The problem remains that it's a common API principle to > accept the broadest possible input. It's not fundamentally wrong to accept > and resolve common URL types, as there's a ton of things that need to read > documents from the Internet by design. However, if this is the default > facility for file handling too, it invents either: > > A responsibility for API users to check that their URL is a file: URL; > A responsibility for API authors to provide separate entry points for file > URLs and remote URLs, and a responsibility for API users to use the right one. > > It would also add a category of errors to common filesystem operations: > "can't do this because the URL is not a file: URL", and a category of > questions that we arguably shouldn't need to ask ourselves. For instance, > what is the correct result of glob()ing a file: URL pattern with a hash or a > query string, should each element include that hash/query string too? > > Félix > >> Le 20 août 2017 à 23:33, Taylor Swift <[email protected]> a écrit : >> >> I think that’s more a problem that lies in Foundation methods that take URLs >> rather than the URLs themselves. A URL is a useful abstraction because it >> contains a lot of common functionality between local file paths and internet >> resources. For example, relative URI reference resolution. APIs which take >> URLs as arguments should be responsible for ensuring that the URL’s schema >> is a `file:`. The new URL type I’m writing actually makes the scheme an enum >> with cases `.file`, `.http`, `.https`, `.ftp`, and `.data` to ease checking >> this. >> >>> On Mon, Aug 21, 2017 at 2:23 AM, Félix Cloutier <[email protected]> >>> 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 >>>> <[email protected]> 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 >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
