<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 17, 2017 at 11:19 PM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="gmail-">On Thu, Aug 17, 2017 at 22:06 Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>> wrote:<br></span><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div><div><div><div><div><div><div><div><div>Okay I can sense this thread getting derailed so I’ll try to address your comments one by one.<br><br></div>* <span style="font-family:monospace,monospace">stderr</span> should go wherever <span style="font-family:monospace,monospace">stdin</span> and <span style="font-family:monospace,monospace">stdout</span> go. Since it’d be silly for a function like `<span style="font-family:monospace,monospace">print(_:separator:terminator:<wbr>)</span>` or `<span style="font-family:monospace,monospace">readLine(strippingNewline:)</span>` to live anywhere but the standard library, then it stands to reason that the <span style="font-family:monospace,monospace">stderr</span> version should also live in the standard library.<br></div></div></div></div></div></div></div></div></div></div></div></blockquote><div dir="auto"><br></div></span><div dir="auto">FWIW, FileHandle.standardInput, FileHandle.standardError, FileHandle.standardOutput, and FileHandle.nullDevice all live in Foundation.</div></div></div></blockquote><div><br></div><div>Yet, we have <span style="font-family:monospace,monospace">print</span> and <span style="font-family:monospace,monospace">readLine</span>, but no <span style="font-family:monospace,monospace">printError</span>.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail_quote"><span class="gmail-"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div><div><div><div><div><div><div><div><br></div>* Foundation is “supposed” to be the core library that does these things, but this isn’t a good thing. Rationale: <br><br> * Foundation is literally an Objective C framework that’s written with Swift syntax. The classes extend <i><span style="font-family:monospace,monospace">NSObject</span></i>. You use them by <i>subclassing</i> them and overriding <span style="font-family:monospace,monospace">open</span> methods. This is patently unswifty. Even parts of Foundation that look swifty on the outside (like `<span style="font-family:monospace,monospace">URL</span>`) are still backed by NS reference types internally.<br><br></div> * To fix this would require a complete rewrite from the ground up, that’s more than a straight port from the Objective C framework. Many on this list have also expressed desire to use this chance to redesign these APIs. Since we’d basically have to rewrite all of it, any effort to modernize Foundation is basically writing a new core library.<br><br></div> * Even if a piece of Foundation was rewritten like a real Swift library, because of the monolith pattern, you still wind up importing a lot of legacy code that shouldn’t be floating around your project. Using the file system tools shouldn’t change `<span style="font-family:monospace,monospace">String</span>`.<br><br></div>* Foundation’s file system capabilities are really just a class wrapper around Glibc/Darwin functions. So in a way, Foundation is already a sort of unified import for C, except it brings in a whole load of Objective C cruft with it.<br><br></div> * Logically, this means in terms of the XY problem, Foundation is on the Y side. Foundation is what happens if you rely on Swift’s C interop to get the job done instead of building a true Swift solution, which would involve Swift quarterbacking all the nasty system calls, instead of Glibc/Darwin doing it.<br><br></div>In conclusion, <br><br></div>* What we need is a modern Swift solution for accessing file systems. <br><br></div>* What we have to do right now is leverage Swift’s C interop to use Glibc/Darwin, while handing imports and platform inconsistencies manually.<br><br></div>* Eventually, the ideal would be for Swift to handle that in Swift, instead of delegating to a platform-dependent C library, or at least standardize things so that a swifty Swift library imports the right C library for you, and exports a platform-independent set of symbols to the user, or a higher level API.<br><br></div>* Foundation is in many ways the worst of both worlds. It handles the Glibc/Darwin import for us, but at the cost of an aging framework that runs against the grain of good Swift design idioms.</div></blockquote><div dir="auto"><br></div></span><div dir="auto">As has been stated on this list by the core team, replacing Foundation or duplicating its functionality is a non-goal of the Swift project. The major focus of several initial proposals, and a considerable amount of effort on this list, was precisely to modernize Foundation so as to offer APIs that conform to Swift guidelines. This work remains ongoing, as there are a number of Foundation value types that have yet to be designed or implemented. And there is a whole open source project devoted to Foundation becoming a viable cross-platform library.</div><div dir="auto"><br></div><div dir="auto">So given these parameters, let's return to what you are talking about: what is deficient about Swift's core file system APIs, and how would you suggest that we address these deficiencies, given that the core team has stated that it is not up for debate that any such changes would be part of Foundation?</div></div></div>
</blockquote></div><br></div><div class="gmail_extra">This probably isn’t the answer you were looking for, but, as explained, <i>all</i> of it is deficient, so long as you still have to subclass <span style="font-family:monospace,monospace">FileManager</span> and catch <span style="font-family:monospace,monospace">CocoaError</span>s. The problem with Foundation is it tries to offer core library features and support bridging to Cocoa types at the same time. Those two goals aren’t very compatible. That’s why there’s such a day and night difference between stdlib and “pure swift” code, and Foundation code. <br><br></div><div class="gmail_extra">So, within the parameters, I would suggest<br> <br></div><div class="gmail_extra">* rewriting the Foundation file system API types as value and protocol types, retire the delegate-driven pattern, and <i>drop</i> <span style="font-family:monospace,monospace">ReferenceConvertible</span> conformance. <br><br></div><div class="gmail_extra"> * value types should be trivial value types, with the possible exception of file streams which need to be closed.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">* separate it as much as possible from other Foundation types, so as to help disentangle the library from <span style="font-family:monospace,monospace">NSNumber</span> and <span style="font-family:monospace,monospace">Date</span>. <br><br></div><div class="gmail_extra"> * inseparable dependencies like <span style="font-family:monospace,monospace">URL</span> should also be rewritten as trivial types. There is no reason for <span style="font-family:monospace,monospace">URL</span> to have reference or copy on write semantics.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">* get submodules into Swift so that Foundation can be split into pieces instead of being imported as a monolith.<br></div></div>