if i remember correctly, the original idea was for swift-algorithms, swift-collections, swift-numerics, etc. to be “incubators” for additions to the standard library so that these APIs could get some real-world usage experience without committing them to the standard library (where there was originally anticipated to be a higher expectation of stability.)
this model broke down for a variety of reasons:
-
pushing legislation through evolution is a harrowing ordeal compared to adding things to third party packages, so types tend to accumulate in the packages and never “graduate”.
-
there’s no organized effort to actually collect “real-world experience” from library users through feedback.
-
these packages have a non-trivial number of users, so in practice they end up being almost as “stable” as the standard library and hard to change.
-
the standard library and the
Swiftmodule are not the same thing, and many have found it more productive to work on toolchain modules in the standard library (e.g.Regex,_Concurrency, etc.) which provide a lot of the same benefits as adding things toSwift(e.g. only have to think about one version tuple, don’t have to download anything from the internet to run CI, etc.) but fewer of the downsides (e.g. making swift harder to use on embedded, high expectation of stability, etc.)
we don’t have a toolchain module for generic algorithms (StringProcessing?), but i think we really should, and this proposal would be an excellent reason to start one.