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

Evolution Discussion
21

Vapor's Core package expresses a target called simply 'libc':

https://github.com/vapor/core/blob/master/Sources/libc/libc.swift

As a result, their Swift files simply say "import libc"

https://github.com/vapor/core/blob/master/Sources/Core/Lock.swift

Alex

···

On 13 Sep 2016, at 20:29, Brian Gesiak via swift-evolution <swift-evolution@swift.org> wrote:

Resurrecting this discussion since the question of "why does Android import Glibc?" came up on this swift-corelibs-foundation pull request: https://github.com/apple/swift-corelibs-foundation/pull/622#discussion_r77848100

I think that it is also important to ask what the real goal here is. Foundation is our cross platform compatibility layer, are there specific deficiencies in the Foundation API that cause a problem here, or is it just that not all of corelibs Foundation is “done” yet?

When I first proposed the idea, I simply wanted to turn these five lines:

    if os(Linux) || os(FreeBSD) || os(Android) || os(PS4)
        import Glibc
    #else
        import Darwin
    #endif

Into this one line:

    import WhateverNameWeDecideUpon

After all, writing five lines of code for the import is painful, and the list of `#if os(...) || os(...) || ...` is always expanding.

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!)

- Brian Gesiak

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

22

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.

···

On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution <swift-evolution@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!)

--
Brent Royal-Gordon
Architechies

23

There is also a similar intent for Zewo’s POSIX:

It would be great to have something included with Swift.

···

On Sep 14, 2016, at 5:59 AM, Alex Blewitt via swift-evolution <swift-evolution@swift.org> wrote:

Vapor's Core package expresses a target called simply 'libc':

https://github.com/vapor/core/blob/master/Sources/libc/libc.swift

As a result, their Swift files simply say "import libc"

https://github.com/vapor/core/blob/master/Sources/Core/Lock.swift

Alex

On 13 Sep 2016, at 20:29, Brian Gesiak via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Resurrecting this discussion since the question of "why does Android import Glibc?" came up on this swift-corelibs-foundation pull request: https://github.com/apple/swift-corelibs-foundation/pull/622#discussion_r77848100

I think that it is also important to ask what the real goal here is. Foundation is our cross platform compatibility layer, are there specific deficiencies in the Foundation API that cause a problem here, or is it just that not all of corelibs Foundation is “done” yet?

When I first proposed the idea, I simply wanted to turn these five lines:

    if os(Linux) || os(FreeBSD) || os(Android) || os(PS4)
        import Glibc
    #else
        import Darwin
    #endif

Into this one line:

    import WhateverNameWeDecideUpon

After all, writing five lines of code for the import is painful, and the list of `#if os(...) || os(...) || ...` is always expanding.

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!)

- Brian Gesiak

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

24

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?

-DW

···

On Oct 5, 2016, at 4:57 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution <swift-evolution@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
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

25

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

I do believe that an even terser name has been suggested in the past for
libc, to avoid the repetition: just `C`.

···

On Wed, Oct 5, 2016 at 5:57 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:

> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution < > swift-evolution@swift.org> wrote:

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

26

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

···

On Oct 5, 2016, at 3:57 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution <swift-evolution@swift.org> wrote:

27

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?

To throw one use case out there, it's used extensively in
corelibs-foundation itself.

···

On Wed, Oct 5, 2016 at 6:14 PM, David Waite via swift-evolution < swift-evolution@swift.org> wrote:

-DW

> On Oct 5, 2016, at 4:57 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:
>
>> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution < > swift-evolution@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
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

28

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!").

···

On Oct 5, 2016, at 4:14 PM, David Waite <david@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?

--
Brent Royal-Gordon
Architechies

29

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.

I don’t know, I kind of take issue with the last point there. I don’t think it’s a foregone conclusion that applications and frameworks aren’t going to need to be using these APIs. As I understand it’s not the goal of Foundation to provide all of the functionality of POSIX. And I know of at least 5 serverside and/or networking libraries which each provide their own abstractions over the POSIX interface. Unfortunately I think that breed incompatibility that bubbles up from underneath.

For example, each library is going to have to redefine their own concepts of a “SystemError” for example (a la this <https://github.com/Zewo/POSIX/blob/master/Sources/POSIX/SystemError.swift&gt; and this <https://github.com/PerfectlySoft/Perfect/blob/master/Sources/PerfectLib/PerfectError.swift#L37&gt; and this <https://github.com/vapor/engine/blob/master/Sources/HTTP/Server/ServerError.swift#L3&gt;, etc). If I want to use two of these libraries now I’ve got conflicting versions of “SystemError”s. What I’m saying is that realistically as system error is a system error and having six different ways to wrap it is not only unfortunate for the library developers, but confusing for the users of the library.

I certainly hear the argument that these should be wrapped in higher level concepts (even perhaps system errors, although there’s only so much wrapping to be done here), but I think we should do some more investigation into whether the cases are actually that narrow. I just want to avoid 10 slightly different thin wrappers around POSIX which are confusing to users of libraries. And each of these wrappers have the same potential for subtle POSIX errors.

Perhaps the way to do it is to make more targeted which are auxiliary to Foundation, like “Networking” or “IO” or “Files” (even though there is overlap here, e.g. system errors as above). The intention here would be not to rearchitect POSIX, but to define base levels of functionality reduce or eliminate the need to make POSIX calls. Or perhaps just widen the reach of Foundation to provide that base functionality.

For example, would a TCPSocket class belong in Foundation? It’s already got HTTPCookies.

Tyler

···

On Oct 5, 2016, at 10:29 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Oct 5, 2016, at 3:57 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution <swift-evolution@swift.org> wrote:

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

30

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.

···

On Oct 5, 2016, at 6:38 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> 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.

--
Greg Parker gparker@apple.com <mailto:gparker@apple.com> Runtime Wrangler

31

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.

I don’t know, I kind of take issue with the last point there. I don’t think it’s a foregone conclusion that applications and frameworks aren’t going to need to be using these APIs.

I respect your opinion, and I agree that it would be “useful” to have a nicer wrapper for POSIX. That said, I stand by the claim that "we can live with this”. We have to pick and choose the battles that are tackled, because we don’t have infinite design bandwidth. Perhaps a better way of saying the above would be say that we should “start” with high level APIs, and see how far that takes us. After exploring those and building out the obvious things needed at higher levels, we can see what is left unaddressed, and decide then whether it makes sense to cover the remaining use cases with a POSIX wrapper or something else.

As I understand it’s not the goal of Foundation to provide all of the functionality of POSIX. And I know of at least 5 serverside and/or networking libraries which each provide their own abstractions over the POSIX interface. Unfortunately I think that breed incompatibility that bubbles up from underneath.

I agree that this is a huge hole in our story, but fortunately this is one of the primary things that the swift server working group is aiming to fix!

-Chris

···

On Nov 30, 2016, at 1:13 AM, Tyler Cloutier <cloutiertyler@aol.com> wrote:

32

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

···

On Oct 5, 2016, at 7:08 PM, Greg Parker <gparker@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.

--
Brent Royal-Gordon
Architechies

33

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

Surely you have just outlined the reason why the ability to import the raw C library is absolutely essential.

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.

To me this reads like you are claiming we can’t have the full capability of a C library now because one day in the future it *might* cause a problem.

···

On 6 Oct 2016, at 03:08, Greg Parker via swift-evolution <swift-evolution@swift.org> wrote:

On Oct 5, 2016, at 6:38 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

34

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

See, I'd assumed that the "unified" Darwin/Glibc would simply be what you
call Platform. And if we're going to have that overlay, what's the point of
also renaming Darwin/Glibc to CPlatform, given that it's going to be
different between platforms, and given that what's not going to be in the
Platform overlay is much more likely to be the divergent bits?

···

On Wed, Oct 5, 2016 at 10:47 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:

> On Oct 5, 2016, at 7:08 PM, Greg Parker <gparker@apple.com> wrote:

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

35

The difference I imagine between `Platform` and `CPlatform` is that `Platform` would do things like:

* Convert `errno`-setting functions to throwing functions.
* Convert many returns by pointer parameter into tuple returns.
* Encapsulate certain structures, like `FILE` and `sockaddr`, which are really awkward to use in Swift.
* Organize free-floating constants into enums.
* Possibly move some operations from free functions to methods.

Whereas `CPlatform` would be basically a straight import of the C libraries, warts and all.

I don't actually imagine that `Platform` would do much platform abstraction except in trivial cases, like the ones currently in stdlib/public/Platform/Misc.c.

···

On Oct 5, 2016, at 8:55 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

See, I'd assumed that the "unified" Darwin/Glibc would simply be what you call Platform. And if we're going to have that overlay, what's the point of also renaming Darwin/Glibc to CPlatform, given that it's going to be different between platforms, and given that what's not going to be in the Platform overlay is much more likely to be the divergent bits?

--
Brent Royal-Gordon
Architechies