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

[Xiaodi Wu]

On Fri, Aug 18, 2017 at 7:39 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:

>
>
> 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.
>

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