> On Aug 18, 2017, at 5:42 PM, Xiaodi Wu via swift-evolution > <firstname.lastname@example.org> wrote: > > On Fri, Aug 18, 2017 at 7:39 PM, Taylor Swift <kelvin1...@gmail.com > <mailto:kelvin1...@gmail.com>> wrote: > > > On Fri, Aug 18, 2017 at 8:09 PM, Xiaodi Wu <xiaodi...@gmail.com > <mailto:xiaodi...@gmail.com>> wrote: > On Fri, Aug 18, 2017 at 6:55 PM, Greg Parker <gpar...@apple.com > <mailto:gpar...@apple.com>> wrote: > >> On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via swift-evolution >> <email@example.com <mailto:firstname.lastname@example.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 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.
I don’t think abandoned is the right term per-se. But the branch of CoreFoundation that is used for the CF inside of swift-corelibs-foundation has moved in a different direction than the one being used for the Windows support (might be better to think of it as a fork that diverged). I would definitely agree that anything of an update for windows support should definitely reach out and work together to see what we can and should update. But as it stands - I don’t think that is fully operational at the current point in time (modulo perhaps Cygwin; which recently had some contributors working on that front). If a contributor wants to revitalize the windows portion I would be very willing to aide in that endeavor. > _______________________________________________ > swift-evolution mailing list > email@example.com <mailto:firstname.lastname@example.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list email@example.com https://lists.swift.org/mailman/listinfo/swift-evolution