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

[Brent Royal-Gordon]

> On Oct 5, 2016, at 4:14 PM, David Waite <david at alkaline-solutions.com> wrote:
> 
> 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?

I see a number of reasons:

	1. Accessing functionality not present in Foundation.

		a. Using subsystems completely omitted in Foundation (e.g. C strings).

		b. Taking finer-grained control of features than Foundation permits.

		c. Using platform-specific features you can't expect Foundation to support (e.g. random ioctls).

	2. Avoiding overhead introduced by Foundation abstractions.

	3. Porting code currently written with libc.

	4. Interoperating with code that uses libc data types (e.g. an embedded HTTP server written in C which uses C-level sockets).

	5. Implementing Foundation itself, or implementing systems that are lower level than Foundation.

The bottom line is, there are a lot of reasons why you might want to work with a lower-level API instead of a higher-level one. Foundation is great, but it's not practical to say that if Foundation isn't doing the job for you, the answer is to improve Foundation—especially since Corelibs Foundation is trying to match a proprietary Apple Foundation which is entirely outside community control.

A CLibc module (or whatever you want to call it) is a simple and practical solution that doesn't preclude future improvements in Foundation or in presenting libc in a more Swifty form in the future. In fact, I believe Foundation and Swift-style libc modules would end up using CLibc.

Now, as for naming: I like using the leading "C" convention because it leaves us room for introducing an overlaid version of the module in the future without breaking source compatibility. Because of this, I wouldn't want to name the module just `C`, because it wouldn't leave room for a Swifty version later.

If we don't want to use words like `Libc` or `POSIX` because the module will import nonstandard APIs too, then I would suggest using `Platform`, or more specifically `CPlatform` for the non-overlaid version. This would make it clear that you're importing platform-provided capabilities, not something provided by Swift. It also implies that some APIs might be platform-specific, so you have at least a hint that you may be below the layers where libraries will abstract away platform differences for you. And the word `Platform` is vague about layering, whereas a name like `OS` might sometimes be inaccurate ("but this call isn't in the OS, it's in the C library!").

-- 
Brent Royal-Gordon
Architechies