<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 also a library somewhat similar to PathKit called FileKit (<a href="https://github.com/nvzqz/FileKit" class="">https://github.com/nvzqz/FileKit</a>). FileKit has some functionality I’m not sure how I feel about, such as different types based on the type of data in the file. It also uses a lot of Foundation for NSBacked types which breaks Linux compatibility. <div class=""><br class=""></div><div class="">I do agree that URL is not the best option for file paths, despite many of the similarities with URL paths, and agree that much of Foundation should be ported to pure Swift in order to increase linux compatibility. <div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 22, 2017, at 10:25 AM, Dave DeLong via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I completely agree. URL packs a lot of punch, but IMO it’s the wrong abstraction for file system paths.<div class=""><br class=""></div><div class="">I maintain an app that deals a <i class="">lot</i> 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 (<a href="https://github.com/kylef/PathKit/" class="">https://github.com/kylef/PathKit/</a>). Working in terms of AbsolutePath and RelativePath (what I’ve been calling things) has been <i class="">extremely</i> 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.</div><div class=""><br class=""></div><div class="">Dave</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 20, 2017, at 11:23 PM, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" 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="">Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><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" 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" class="">https://github.com/kelvin13/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>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>