> On Aug 18, 2017, at 5:42 PM, Xiaodi Wu via swift-evolution 
> <swift-evolution@swift.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 
>> <swift-evolution@swift.org <mailto: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 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
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to