On Fri, Aug 18, 2017 at 7:39 PM, Taylor Swift <kelvin1...@gmail.com> wrote:
> > > 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. > 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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
