1

Currently, Apple holds Swift related frameworks in Apple github account beside other projects.

On the other hand, there are many proposals about adding features like ordered set/dictionary in which community is reluctant to add it to stdlib and make it bloated.

I suggest we must create a separate account (e.g. swift-corelibs) and move Foundation, Dispatch, NIO, NIO-http2, NIO-ssl and Protobuf into the new account.

In future, we can add other frequently-requested features that which does not need compiler magic into this account. This account paves way to define a painless way to automatically import frequently used frameworks in Swift projects.

We can also reintroduce features like Random as a corelib repository and slim down stdlib, and we can add non-Apple popular repositories after community approval and standardizing (with an evolution topic).

On the compiler side, we must implement something that search these repositories and automatically download and import these frameworks for user. User can easily declare import NIO and compiler will find coresponding repository and imports code. Xcode may bundle these frameworks. But this appoach allows any other IDE to have a standard way to import standard frameworks. This approach means you pay for what you use.

To ensure compatibilty, every repository must include one branch for every Swifr release, like swift-4.2 or swift-5.0 and compiler only checks branch which has same version. This means easier evolution for projects as they don't need keep master branch compatible with old releases.

2 Likes
2

To be clear, not all of Apple's open source Swift projects are part of the Swift.org umbrella. The list of repositories officially part of the Swift project are listed on Swift.org.

Swift's open source ecosystem contains various projects written by different people that aren't part of the Swift.org umbrella. It's fine for Apple to publish open source projects written in Swift that stand on their own without being part of the Swift project itself.

It's true that there is a balancing act on the right "core" capabilities that the Standard Library should contain, and the community continues to discuss that balance. However, I do think containers like ordered set/dictionary could have a place in the Standard Library, and the "bloat" concerns as far as code size will be partially mitigated once Swift achieves ABI stability. That doesn't mean the Standard Library should grow without bound, but with ABI stability it means that the Standard Library can be shipped by OS vendors and thus not impact the distribution size of Swift applications.

There's a bunch of different projects here, so it's worth teasing out the Standard Library and Core libraries from the others. The Standard Library and Core Libraries (e.g., Foundation and Dispatch) are considered to be bedrock APIs that are available in the core Swift distribution. As such, they are part of the Swift open source project. NIO and Protobuf are currently independent open source projects that are not part of the Swift project, and are meant to be available for anyone interested to use — just like any other Swift open source project that exists in the world.

I'm not certain what you mean by "account". It seems like there are multiple concepts being discussed here, but there are a variety of schemes in the future that Swift could make available for users to import and distribute libraries. Including a core set of libraries as part of "core Swift" is one of them. The Swift Package Manager is another, and there are other options as well. What precisely "painless way to automatically import" means really comes down to the tooling story, and expectations about portability and availability of specific APIs.

Much of what is described here is part of the intended charter of the Swift Package Manager. The package manager allows APIs to describe different versions of the APIs based on semantic versioning, and Swift versioning.

Aside from the package manager, there is an interesting question of how can more libraries be added to "core Swift". I've been thinking about possible models here, and one model being considered is to take inspiration from Boost and have a way for libraries that start their lives as independent open source projects to be proposed and adopted into core Swift. How precisely that would work, and the criteria to add a core library to Swift, is something that needs further thought and discussion. It's something I'm considering, and will circle back with the community once I have a more concrete idea of how this might work.

3 Likes