[swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[Chris Lattner]

On Oct 5, 2016, at 3:57 PM, Brent Royal-Gordon <brent at architechies.com> 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.

I’ve come around to agree with this position.  I think it makes sense to have a cross platform “libc” which is an alias for darwin, glibc, or whatever, and just leave it at that.

Other proposals for a “POSIX” module have gotten bogged down because inevitably the idea comes up to make the resultant API nicer in various ways: rename creat, handle errno more nicely, make use of multiple return values, … etc.  The problem with this approach is that we don’t *want* people using these layer of APIs, we want higher level Foundation-like APIs to be used.

That’s why I think the best way to split the difference is to do as you suggest.  This allows the implementation of Foundation (and similar level of APIs) to be nicer, but not get bogged down trying to figure out how to clean up POSIX.

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

I think we should formally decide that a “nice” wrapper for libc is a non-goal.  There is too much that doesn’t make sense to wrap at this level - the only Swift code that should be using this is the implementation of higher level API, and such extremely narrow cases that we can live with them having to handle the problems of dealing with the raw APIs directly.

-Chris