<div>On Thu, Aug 17, 2017 at 22:06 Taylor Swift <<a href="mailto:kelvin13ma@gmail.com">kelvin13ma@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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:)</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><div dir="auto">FWIW, FileHandle.standardInput, FileHandle.standardError, FileHandle.standardOutput, and FileHandle.nullDevice all live in Foundation.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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><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 dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 17, 2017 at 8:16 PM, Xiaodi Wu <span><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span>On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift <span><<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>I don’t think the “is this library functionality or standard library functionality” argument is worth having, but if <span style="font-family:monospace,monospace">stdout</span> and <span style="font-family:monospace,monospace">stdin</span> are first-class citizens in the Swift world, so should <span style="font-family:monospace,monospace">stderr</span>.<br><br></div>As for bringing Foundation into the discussion, you can’t really talk about Foundation without also talking about the mountains of problems that come with the monolith pattern. But that’s a completely different conversation to be had.<br></div></blockquote><div><br></div></span><div>I'm not sure what you're getting at here, but I don't believe you've addressed my question, which is: it's been firmly decided that I/O belongs in Foundation, and Foundation does in fact offer such facilities--what is missing from those facilities, and how can we fill it out?</div><div><div class="m_-6169918068543336267h5"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_-6169918068543336267m_-8779740336557727265HOEnZb"><div class="m_-6169918068543336267m_-8779740336557727265h5"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 17, 2017 at 7:13 PM, Xiaodi Wu <span><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">IMO, you’re touching on at least three or four separate topics here. Daniel touched on several, but just some comments/questions:<br><br>* Standard error output is something that’s been discussed here previously. I believe the last pitch had something like StandardError being added to the standard library as a TextOutputStream.<br><br>* Foundation is supposed to be the core library that provides file system access facilities. What’s missing, and can we add it to Foundation?<br><br><div class="gmail_quote"><div><div class="m_-6169918068543336267m_-8779740336557727265m_3160978602143015819h5"><div>On Thu, Aug 17, 2017 at 17:50 Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-6169918068543336267m_-8779740336557727265m_3160978602143015819h5"><div>Python’s <a href="https://docs.python.org/2/library/os.path.html" target="_blank">os.path</a> is a nice abstract model for doing path manipulations. Maybe Swift could get a struct like `Filepath` or something on which these operations could be done.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 17, 2017 at 6:47 PM, Taylor Swift <span><<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar <span><<a href="mailto:daniel_dunbar@apple.com" target="_blank">daniel_dunbar@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I know this has come up before without any action, but having the standard C library be packaged under `Darwin` on OSX and `Glibc` under Linux is something that’s really becoming an issue as the Swift package ecosystem matures. Right now a lot of packages are a lot less portable than they could be because somewhere along the dependency line, there is a package that only imports the C library for one platform. Unifying it under one import would allow people to write packages that are portable by default.<br>
<br>
</span>What we (SwiftPM) have done for now is use a `libc` target to start by normalizing the name:<br>
<a href="https://github.com/apple/swift-package-manager/tree/master/Sources/libc" rel="noreferrer" target="_blank">https://github.com/apple/swift-package-manager/tree/master/Sources/libc</a><br>
(and in the past, when we find missing things in Glibc getting them added to the compiler). Also, this name is technically a misnomer, but we couldn’t think of a better one (“os” might have been a good one).<br>
<br>
Unfortunately, I think this change alone is really only the tip of the iceberg. It would be nice to not have it the difference, but we found we very quickly needed several other layers on top to get to having a relatively stable cross-platform base:<br>
<a href="https://github.com/apple/swift-package-manager/tree/master/Sources/POSIX" rel="noreferrer" target="_blank">https://github.com/apple/swift-package-manager/tree/master/Sources/POSIX</a><br>
<a href="https://github.com/apple/swift-package-manager/tree/master/Sources/Basic" rel="noreferrer" target="_blank">https://github.com/apple/swift-package-manager/tree/master/Sources/Basic</a><br>
<br>
My hope is that one minimal improvement we can get soon is multi-package repo support in SwiftPM, which will at least allow us to share those targets & functionality with other packages.<br>
<span><br>
> Since I think this got hung up in the past over “what constitutes” a universal libc, I propose a unified package should just consist of the functionality that is common between Darwin and Glibc right now, since those are the only two supported platforms anyway.<br>
<br>
</span>What would the concrete proposal be? It isn’t trivial to determine that subset and make it well-defined what the exact API is. Is the proposal to just to pick a standard name, and reexport Darwin and Glibc from it?<br></blockquote><div><br></div></span><div>I don’t know if it’s actually this simple, but could it just be the symbols that are defined in both modules?<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> Alternatively, Swift could make it a priority to get basic functionality like file IO and math functions shipped with the compiler, which would probably cover 98% of cases where people currently import Darwin/Glibc. A large portion of the standard C libraries are redundant to the Swift standard library anyway.<br>
<br>
</span>I’m not sure I agree with these statements about the percentages. For some clients (I’m biased, the areas I work in tend to be in this boat), what we largely need is good platform-agnostic access to the POSIX APIs. This is a hard problem to make a good cross-platform API for (esp. if Windows support is in your head), and which many projects struggle with (Netscape :: NSPR, LLVM :: libSupport, many many more).<br>
<br>
The sticking point I see is this: if the proposal is just to unify the name & that doesn’t actually buy us all that much (still need standard layers on top), then have we really solved enough of a problem to be worth standardizing on?<br>
<br>
+1 in general agreement with the meta-issue being an important one to discuss.<br>
</blockquote></span></div><br></div><div class="gmail_extra">There probably is an XY issue at play here; what we <i>really</i> need is a way to access the file system built into the standard library. (Math functions are a separate, beleaguered topic for a different thread.) Having support for outputting to `stderr` is also something I’d really like. Going through Glibc/Darwin is just one way to solve this.<br></div></div>
</blockquote></div><br></div></div></div><span>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</span></blockquote></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</blockquote></div></div>