It could be problematic to initialize, however. You would need to know Scheme in URL<Scheme> ahead of initialization time for at least two reasons: first because value types aren't polymorphic, and second because the size of a type can depend on its generic parameters.
(If we have a good solution for both, then that would be great, yes.) Félix > Le 21 août 2017 à 09:28, Robert Bennett <[email protected]> a écrit : > > 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] <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] <mailto:[email protected]>> a écrit : >>>> >>>> Okay so a few days ago there was a discussion >>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038923.html> >>>> 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 <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] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
