On Fri, Aug 18, 2017 at 6:55 PM, Greg Parker <gpar...@apple.com> wrote:
> > 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> > 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 ugly. > > 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. > So that's a good starting point for the discussion. 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 "complicated or non-portable things" 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?
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
