[swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"
david at alkaline-solutions.com
Wed Oct 5 18:14:37 CDT 2016
If we are pulling in functions/structures not defined by the C standard library or by POSIX, I’d be reluctant to support a standard name. It would be troublesome if someone thought that they were cross-platform but turned out to use strfry() heavily
I certainly wonder what people specifically want to bring the C standard library or POSIX libraries in for - is it compatibility with third party libraries? Functionality missing in Foundation?
> On Oct 5, 2016, at 4:57 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution <swift-evolution at swift.org> wrote:
>> I hadn't thought about a unified overlay for POSIX. I think the simplified import alone has benefit to warrant its own evolution proposal. Would it be possible to have a separate discussion for the POSIX overlay idea? Or is there a reason that I'm missing that prevents the import from being viable on its own? (Apologies in advance if there's an obvious answer to this question!)
> I've heard the argument before that we should do a full overlay, but I think this is becoming a case of the perfect being the enemy of the good. Having some sort of "just import whatever the system libc is called" module would be a significant improvement in practice over the state of the art, even if we don't do any other adaptation.
> Here's what I would suggest. We have a convention for exposing "raw" imports of C libraries: you call them `C\(libraryName)`. So I would suggest we introduce a `CLibc` module which provides a raw import of the system's libc. If we later decide to do a full-featured overlay, that's great—we can call it `Libc`. But `CLibc` by itself would be an improvement over the status quo and a step in the right direction.
> Brent Royal-Gordon
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution