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

[Taylor Swift]

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