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

[Brent Royal-Gordon]

> On Oct 5, 2016, at 7:08 PM, Greg Parker <gparker at apple.com> wrote:
> 
>> Now, as for naming: I like using the leading "C" convention ("CLibc") 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.
> 
> I don't think separating the raw C library translation from the pretty Swift wrapper works, at least not for everybody. The problem is that the raw translation is going to have functions that the pretty wrapper does not. (Perhaps the pretty wrapper is new and incomplete. Perhaps an OS has added functions and the pretty wrapper has not caught up yet.)  If you try to import both then you end up with the same problems of name collisions today and source incompatibility in the future when the pretty wrapper grows.

I didn't mean that you could import both—merely that, if you used CLibc (or CPlatform) today, the introduction of the pretty Libc or Platform in a future version of Swift wouldn't affect your existing code.

As for handing unsupported features, I'd like you to be able to say something like (using a version of today's syntax):

	import Platform
	import func CPlatform.newfunc(_:_:)

Which would hopefully mean that, if a future version of Libc added newfunc(_:_:), the CLibc version—which is the one we explicitly requested—would shadow it. (Perhaps when you rebuilt against the newer version of Libc, you'd get a shadowing warning that would hint to you that you don't need to pull that function in from CLibc anymore.)

-- 
Brent Royal-Gordon
Architechies