<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">A responsibility for API users to check that their URL is a file: URL;</li><li class="">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.</li></ul><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">Félix</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 20 août 2017 à 23:33, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 `<span style="font-family:monospace,monospace" class="">file:</span>`. The new URL type I’m writing actually makes the scheme an enum with cases `<span style="font-family:monospace,monospace" class="">.file</span>`, `<span style="font-family:monospace,monospace" class="">.http</span>`, `<span style="font-family:monospace,monospace" class="">.https</span>`, `<span style="font-family:monospace,monospace" class="">.ftp</span>`, and `<span style="font-family:monospace,monospace" class="">.data</span>` to ease checking this.<br class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Aug 21, 2017 at 2:23 AM, Félix Cloutier <span dir="ltr" class=""><<a href="mailto:felixcloutier@icloud.com" target="_blank" class="">felixcloutier@icloud.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Félix</div><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="m_-5951878550971829595Apple-interchange-newline"></div></div><div class=""><div class=""><div class="h5"><div dir="ltr" class=""><div class=""><div class="">Okay so a few days ago there was a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038923.html" target="_blank" class="">discussion</a> 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 `<span style="font-family:monospace,monospace" class="">URL</span>` type (which is currently little more than a wrapper for NSURL), so I’ve just started a pure Swift URL library project at <<a href="https://github.com/kelvin13/url" target="_blank" class="">https://github.com/kelvin13/<wbr class="">url</a>>.<br class=""><br class=""></div>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.</div><div class=""><br class=""></div><div class="">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.)<br class=""></div><div class=""><br class=""></div>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!<br class=""></div></div></div>
______________________________<wbr class="">_________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div></div></div>
</div></blockquote></div><br class=""></div></div></body></html>