On Fri, Aug 18, 2017 at 8:09 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 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? > > > 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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
