Swift Collections and Swift Numerics are great and commonly used, and libraries like them are usually in standard libraries in other programming languages.
Any plan to merge these libraries into Swift core library? Any reasons why they are separate from core library?
Two reasons:
Having said that, I think the plan of record was for at least some of the ordered collections to be proposed for inclusion into the standard library at some point.
I don't know what the plan for Numerics is.
Folks should also carefully consider the less-visible costs of tossing everything into the standard library.
Sure, putting APIs in the standard library means you avoid an explicit package dependency, but if you're targeting Apple platforms you're now limited by what version of the OS you're running on because the standard library is part of the OS. Any time a new API comes out in one of those packages, it would require an OS availability check and/or upgrading to the latest OS to use the new stuff.
Whereas if you're using it as a package, as long as the new features don't require corresponding new standard library features, you can just upgrade to the new version of the package immediately without affecting your minimum deployment version.
That's not only to say that the code in the packages today would potentially need heavy-weight reviews before shipping in the standard libraryā¦ it's also about the code tomorrow.
The friction to shipping new code in the packages is lightweight by design compared to shipping new code in the standard library. And that can be a Good Thing.
Also, I think having a standardized code packaging system removes a lot of the pressure put on, for instance, WG21 to just throw things into the standard library.
The other side of this is tying the release of your package code to the release cycle of the standard library. Release branches soakā¦ and soakā¦ and soak some more. I understand it's a big project and a big language. A lot of moving pieces are depending on finding bugs in soak.
Independent packages can move faster. You obviously want CI and testing and probably some kind of soak period. But if you and the maintainers think this code needs to ship you can ship ASAP.
one argument in favor of integrating swift-collections and swift-numerics (and probably, swift-algorithms as well) into the toolchain is that it would enable using those libraries in single-file scripts. more generally, it would alleviate a lot of common gripes with the language when using:
Package.swift manifestsas a āproā user iām not sure if these benefits outweigh the costs of including them in the toolchain. but we need a better answer than āstart developing a full-on SwiftPM Packageā when people run into these problems, as they tend to crop up when people first start using the language and have an outsize impact on whether they continue learning Swift or not.
I'll add another reason to the list of why these things make sense as packages rather than libraries. Their nature is such that they should always be fully inlined and specialized. As such, you really don't want an ABI-stable binary framework containing one of the swift collection types, because if you ever actually called into the framework, something will have gone horribly wrong. Distribution as source makes much more sense for these things.
Can you clarify what you mean by āif you ever actually called into the framework, something will have gone horribly wrongā? I donāt quite understand why an ABI-stable binary framework is problematic for inlining and specialization. Wouldnāt the Swift Standard Library, which is also ABI-stable, face the same limitations? How does it avoid these issues while still maintaining high-performance characteristics for its collection types?
The point is that if the code is inlined into your application, you'll never actually be accessing the functions in the library installed on the system (because the code was copied into your app).
This is also true for some existing parts of the standard library, but because they are required to be ABI stable, they can never be optimized or improved in a way that affects their ABI (e.g. altering function parameters, struct layouts, or internal side-effects).
And yes, it's absolutely a problem. The cost of stdlib ABI stability was that some mistakes can never be rectified - there are bad API decisions or poor optimizations that we are now stuck with forever - but ABI stability was the necessary price for every Swift app not having to include its own copy of the entire stdlib, and the ability to have Swift APIs in the OS instead of being forever stuck with Objective-C.
With considerable difficulty, a lot of UnsafePointer use, and some compiler awareness of the semantics of specific methods[1]. One of the reasons we're so excited about Span is improving this situation somewhat.
grep the stdlib for "@_semantics(array." ā©ļø
As a related point of consideration, from a package health POV, swift-numerics does not seem to be maintained well. The last tagged release was 1.0.2, released on November 18th, 2021.
swift-async-algorithms has also been frequently criticized by the community as not evolving fast enough (I personally hold this view more for swift-numerics rather than swift-async-algorithms).
All of this is to say that even though part of the rationale as I understand it for keeping these packages out of the Swift core library was so that they could move faster, they do not seem to be doing so.
I definitely think these libraries need active maintenance to be considered as stable even for those consuming it as a SwiftPM package, let alone the Swift standard library.
What bug fixes do you need tagged in a release?
i donāt personally view swift-numerics as a Problem Child within the Swift Package Ecosystem (there are plenty of packages that are), but i understand i may be in the minority here.
my main dissatisfaction with swift-async-algorithms is about binary size, the package badly needs to be divided into smaller modules (e.g. AsyncChannel) and at present, using just one type from that package adds nearly 10 MB to the compiled binaries!
so right now, i am not using swift-async-algorithms at all, iām actually literally extracting source files from its repository and including them ad-hoc in various projects. 
i donāt know if upstreaming swift-async-algorithms to the Swift toolchain would solve any of those problems though. if anything, it seems like it would make it worse, by making it harder to reorganize the package into modules.
This is not true, or at least it doesn't have to be. We backported Concurrency, and we can backport any of these, all the same. It's more work that Apple doesn't want to do, though; they're very fond of telling everyone to either update to or target only the latest systemsā¦
Inb4 "there are tradeoffs" yes, and I believe the benefits far outweigh the costs here. So did everyone else when we demanded Concurrency be backported.
Iām not sure I fully understand the intent of question.
There seem to have been a considerable number of commits since the date of the last tagged release, including bug fixes.
It does not inspire confidence nor trust to observe such a massive drift between the tip of main right now and the last tagged release.
There are some bug fixes on main, but theyāre mostly fixes for features-in-progress on main. If someone needs a specific fix in a tag in the meantime, Iāll be happy to create one.
Excuse my ignorance, but why are releases not being made regularly if regular improvements are coming in, regardless of what they're for? This goes for any Apple-owned package. I.E.:
I can go onā¦
And if they really are for specific features, why are they not on feature branches instead of main?
@vatsal I feel I have to step in and point out how hostile your wording is here.
Work on new features in a package are perfectly reasonable to be done on main and the idea that unreleased new feature work (especially in a library like this, where features aren't entangled with each other) constitutes "massive drift" is misplaced. Similarly, claiming those features not being released yet indicates that the package is "not maintained well" is also inappropriate.
Steve is asking if you are aware of bugs for which a non feature release should be cut. That is, to outline what active maintenance (not feature additions) is needed. It is a reasonable question, and one you haven't answered.
We all understand people often would like certain features sooner, or for maintainers to work on different things. Community input into that process ā about what features they are looking for ā is useful. But your comments are not that. Your comments are instead just rock throwing about a perceived link between quality and release cadence. This is not OK.
