[Suggestion] Add Swift-Collections library to stdlib

  1. Swift-Collection is hosted on GitHub. Hotlinking to Swift-Collection official repository through Xcode can result in usability issues when being used in Mainland China except using a virtual private network. There are non-official repo mirrors in Gitee, but these mirrors cannot sync releases from GitHub.

  2. It is currently impossible to use a Swift package inside a Swift script file.

From the announcement post:


@ShikiSuen thanks for bringing this up! I wasn't aware of point 1. (If you haven't already, would you be able/willing to also file a feedback at https://feedbackassistant.apple.com about it?)

Instead of adding the entire package as is to the stdlib in one big proposal, the plan (well, my plan, for what it's worth) is to instead propose individual data structure implementations for addition to/near the stdlib. (The three existing data structure implementations are just a start. We have several new excellent implementations waiting to land in a new feature release, and there are several years' worth of additions that could come later.)

The primary prerequisite for doing this is that we come across some concrete, pressing need to have a particular data structure implementation ship as an integral part of every Swift distribution. This is quite a high bar -- at first approximation, it requires that we want to add public API to the stdlib (or near the stdlib) that operates on one of these data structures. (For example: we want to add a public function that takes or returns a Deque.) So far, we have not found a need to use the existing types this way.

(Note: merely using these packages in the implementation of the compiler (or in one of the auxiliary libraries such as StdlibUnittest) does not require them to ship as part of the stdlib -- the compiler is quite able to build them in their package form.)

The two issues you raised above are very real (and very painful). However, they apply to all packages within the Apple Package Collection (not just swift-collections!), and I think they can and should be resolved without adding all of these packages to the Standard Library!


I would suggest to work around this by a reverse proxy, which can serve as a dependency mirror in SwiftPM. I don’t know if Xcode supports this feature, but I would suggest you report this to Apple if it doesn’t.

In the future, once the official package registry is set up, I would look into providing a static mirror based in China mainland:)

1 Like

Xcode not support set-mirror function

You can see a full write-up of a proof of concept of the feature here. There remains some work (eg. moving the functionality into the frontend, improving manifest generation and providing IDE support), but it should eventually solve the problem.