<div dir="ltr">On Fri, Aug 18, 2017 at 7:39 PM, Taylor Swift <span dir="ltr">&lt;<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 18, 2017 at 8:09 PM, Xiaodi Wu <span dir="ltr">&lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>On Fri, Aug 18, 2017 at 6:55 PM, Greg Parker <span dir="ltr">&lt;<a href="mailto:gparker@apple.com" target="_blank">gparker@apple.com</a>&gt;</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 style="word-wrap:break-word;line-break:after-white-space"><span><br><div><blockquote type="cite"><div>On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_3781229052794196898m_-9206094417763070344m_-160126522738321039Apple-interchange-newline"><div><div dir="ltr">On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift <span dir="ltr">&lt;<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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><div>I&#39;m not sure what you&#39;re getting at here, but I don&#39;t believe you&#39;ve addressed my question, which is: it&#39;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></div></div></blockquote><br></div></span><div>Lots of I/O functionality is missing from Foundation. Foundation&#39;s design from time immemorial is that generally only relatively simple and high-level operations are available in Foundation itself, and if you want to do complicated or non-portable things then you are expected to drop down to POSIX or other C interfaces. That design works less well in Swift than it did in Objective-C because Swift&#39;s interface with C, especially low-level C, is often ugly.</div><br><div>Simple example: there is no way to access file information directly via NSFileHandle. You need to call NSFileHandle.fileDescriptor and pass that to  fstat() or fcntl(). The NSFileHandle API in general is sparse and wholly inadequate for sophisticated I/O.</div></div></blockquote><div><br></div></span><div>So that&#39;s a good starting point for the discussion.</div><div><br></div><div>What, in your opinion, should be the way forward in addressing this situation? Is there a realistic chance of writing a single comprehensive, cross-platform API that makes possible currently &quot;complicated or non-portable things&quot; on both macOS/iOS/tvOS/watchOS and Linux, and potentially Windows? If so, does that fit within the general category of filling out the currently sparse Foundation APIs or would that be a matter for a separate library? In the alternative, is it the right solution to make dropping down to POSIX marginally easier by re-exporting C APIs under a unified name, without attempting a single cross-platform API?</div><div><br></div><div><br></div></div></div></div>
</blockquote></div></div><div class="gmail_extra"><br></div></div></div><div class="gmail_extra">For what it’s worth, CoreFoundation appears to support windows environments, at least for things like path manipulation. However atm it’s not very relevant as Swift doesn’t run on Windows rn.<br></div></div>
</blockquote></div><br></div><div class="gmail_extra">If I recall, the CoreFoundation code for Windows is from a long-abandoned port that no longer works, to the point that it is thought unsuitable as a basis for a modern port.</div></div>