> On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via swift-evolution 
> <swift-evolution@swift.org> wrote:
> On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift <kelvin1...@gmail.com 
> <mailto:kelvin1...@gmail.com>> wrote:
> I don’t think the “is this library functionality or standard library 
> functionality” argument is worth having, but if stdout and stdin are 
> first-class citizens in the Swift world, so should stderr.
> 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.
> 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?

Lots of I/O functionality is missing from Foundation. Foundation'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's interface with C, especially low-level C, is often 

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.

Greg Parker     gpar...@apple.com <mailto:gpar...@apple.com>     Runtime 

swift-evolution mailing list

Reply via email to