Foundation additions about swift-system

[milseman]

@karwa that's certainly how things are starting to shake out, at least for implementation details. I think it would be nice to formally establish this layering. Foundation will (likely) forever pull in the Darwin module though, so we'll still have the C APIs as well as System.

@Catfish-Man thoughts?

[milseman]

@lorentey do you know what the story is with cross-import overlays, especially in a package build environment?

[milseman]

We can definitely have the code in System, but I'm not sure how the build system side of things would work out with SwiftPM. @abertelrud do you know how SPM handles cross-import modules?

[lorentey]

One thing we could do is to put the combo overlay APIs into a separate build product that must be imported explicitly.

[karwa]

I think it would be better if these went the other way - i.e. in Foundation.

The reason is that the natural layering of these 2 libraries would have swift-system sit at the bottom, and for Foundation to depend on it and use it, and for swift-system not to depend on Foundation. For example, it would be fantastic if FS APIs such as FileManager would also accept a FilePath without requiring that it goes through String.

[hassila]

I think it would be better if these went the other way - i.e. in Foundation.

The reason is that the natural layering of these 2 libraries would have swift-system sit at the bottom, and for Foundation to depend on it and use it, and for swift-system not to depend on Foundation.

+1 on that, it's nice to be able to build server-side swift without pulling in Foundation at all (and swift-system is definitely useful for that context).