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

[Taylor Swift]

On Fri, Aug 18, 2017 at 8:09 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> 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?
>
>
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170818/f86c783c/attachment.html>