[swift-evolution] pitch: Unified libc import (again)

[Xiaodi Wu]

On Fri, Aug 18, 2017 at 6:55 PM, Greg Parker <gparker at apple.com> wrote:

>
> On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift <kelvin13ma at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170818/ea7aaca4/attachment.html>