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

[Xiaodi Wu]

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?


On Thu, Aug 17, 2017 at 7:13 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>> IMO, you’re touching on at least three or four separate topics here.
>> Daniel touched on several, but just some comments/questions:
>>
>> * Standard error output is something that’s been discussed here
>> previously. I believe the last pitch had something like StandardError being
>> added to the standard library as a TextOutputStream.
>>
>> * Foundation is supposed to be the core library that provides file system
>> access facilities. What’s missing, and can we add it to Foundation?
>>
>> On Thu, Aug 17, 2017 at 17:50 Taylor Swift via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> Python’s os.path <https://docs.python.org/2/library/os.path.html> is a
>>> nice abstract model for doing path manipulations. Maybe Swift could get a
>>> struct like `Filepath` or something on which these operations could be done.
>>>
>>> On Thu, Aug 17, 2017 at 6:47 PM, Taylor Swift <kelvin13ma at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar <daniel_dunbar at apple.com
>>>> > wrote:
>>>>
>>>>>
>>>>> > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <
>>>>> swift-evolution at swift.org> wrote:
>>>>> >
>>>>> > I know this has come up before without any action, but having the
>>>>> standard C library be packaged under `Darwin` on OSX and `Glibc` under
>>>>> Linux is something that’s really becoming an issue as the Swift package
>>>>> ecosystem matures. Right now a lot of packages are a lot less portable than
>>>>> they could be because somewhere along the dependency line, there is a
>>>>> package that only imports the C library for one platform. Unifying it under
>>>>> one import would allow people to write packages that are portable by
>>>>> default.
>>>>>
>>>>> What we (SwiftPM) have done for now is use a `libc` target to start by
>>>>> normalizing the name:
>>>>>   https://github.com/apple/swift-package-manager/tree/master/
>>>>> Sources/libc
>>>>> (and in the past, when we find missing things in Glibc getting them
>>>>> added to the compiler). Also, this name is technically a misnomer, but we
>>>>> couldn’t think of a better one (“os” might have been a good one).
>>>>>
>>>>> Unfortunately, I think this change alone is really only the tip of the
>>>>> iceberg. It would be nice to not have it the difference, but we found we
>>>>> very quickly needed several other layers on top to get to having a
>>>>> relatively stable cross-platform base:
>>>>>   https://github.com/apple/swift-package-manager/tree/master/
>>>>> Sources/POSIX
>>>>>   https://github.com/apple/swift-package-manager/tree/master/
>>>>> Sources/Basic
>>>>>
>>>>> My hope is that one minimal improvement we can get soon is
>>>>> multi-package repo support in SwiftPM, which will at least allow us to
>>>>> share those targets & functionality with other packages.
>>>>>
>>>>> > Since I think this got hung up in the past over “what constitutes” a
>>>>> universal libc, I propose a unified package should just consist of the
>>>>> functionality that is common between Darwin and Glibc right now, since
>>>>> those are the only two supported platforms anyway.
>>>>>
>>>>> What would the concrete proposal be? It isn’t trivial to determine
>>>>> that subset and make it well-defined what the exact API is. Is the proposal
>>>>> to just to pick a standard name, and reexport Darwin and Glibc from it?
>>>>>
>>>>
>>>> I don’t know if it’s actually this simple, but could it just be the
>>>> symbols that are defined in both modules?
>>>>
>>>>
>>>>>
>>>>> > Alternatively, Swift could make it a priority to get basic
>>>>> functionality like file IO and math functions shipped with the compiler,
>>>>> which would probably cover 98% of cases where people currently import
>>>>> Darwin/Glibc. A large portion of the standard C libraries are redundant to
>>>>> the Swift standard library anyway.
>>>>>
>>>>> I’m not sure I agree with these statements about the percentages. For
>>>>> some clients (I’m biased, the areas I work in tend to be in this boat),
>>>>> what we largely need is good platform-agnostic access to the POSIX APIs.
>>>>> This is a hard problem to make a good cross-platform API for (esp. if
>>>>> Windows support is in your head), and which many projects struggle with
>>>>> (Netscape :: NSPR, LLVM :: libSupport, many many more).
>>>>>
>>>>> The sticking point I see is this: if the proposal is just to unify the
>>>>> name & that doesn’t actually buy us all that much (still need standard
>>>>> layers on top), then have we really solved enough of a problem to be worth
>>>>> standardizing on?
>>>>>
>>>>> +1 in general agreement with the meta-issue being an important one to
>>>>> discuss.
>>>>>
>>>>
>>>> There probably is an XY issue at play here; what we *really* need is a
>>>> way to access the file system built into the standard library. (Math
>>>> functions are a separate, beleaguered topic for a different thread.) Having
>>>> support for outputting to `stderr` is also something I’d really like. Going
>>>> through Glibc/Darwin is just one way to solve this.
>>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170817/7a26f181/attachment.html>