> On Oct 5, 2016, at 4:14 PM, David Waite <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
