TLDR: We'd like to officially declare Swift Collections source stable and tag version 1.0 of it in the next week or two. Please speak up now if you have something you'd like to see changed in
OrderedDictionary -- this is the last opportunity to (easily) fix any API issues.
Swift Collections currently declares its entire API unstable. However, as it gets adopted by more and more projects, it is becoming increasingly unlikely we would be able to make source breaking changes in future releases. It makes sense to accept this fact and declare the package source stable now.
Our plan is to tag version 1.0 of swift-collections in the next week or two. I have already created a branch for the new release (
release/1.0), using the latest 0.0.5 tag as the starting point.
The 1.0 release will ship with the original three collection types,
We expect to observe the rules of Semantic Versioning. Changes to the public API of the package that are expected to cause build failures in adopters can only be shipped in a new major release. The same goes for behavioral changes that are likely to change the meaning of existing code.
Note: Pretty much every change can technically break someone, so this isn't an exact science. At the end of the day, whether a change introduces acceptable risk boils down to a judgment call made by the package maintainers, based on information supplied by the community. When we get it wrong, I expect we will be able to correct mistakes after the fact by tagging a subsequent new release.
The public API of version 1.0 of the swift-collections package will consist of non-underscored declarations that are marked
public in the following modules:
For a list of public APIs defined by each public type, see the documents in the Documentation folder of the repository.
Note that no part of the test suite nor benchmarks are included in the package's public interface -- these may continue to change at whim. (This includes the entire contents of the
By "underscored declarations" we mean declarations that have a leading underscore anywhere in their fully qualified name. For instance, here are some names that wouldn't be considered part of the public API, even if they were technically marked
Underscored APIs may continue to change in any release, including patch releases.
Future minor versions of the package may introduce changes to these rules as needed.
Given that this is a core package that is likely to become a dependency of many projects, I expect we will rarely if ever be able to release new major versions of it.
The stated intention of this package is to serve as a proving ground for stdlib additions, so we'll have at least one opportunity to make major API changes, at the time we propose these types for addition to the Standard Library.
In the (hopefully unlikely) case that we need to make sweeping API changes before that, we have the option to do that by adding new variants of existing types without removing the original implementations.
A number of wonderful new data structure implementations are currently getting prepared to land on the
main branch -- these will not be part of the 1.0 release, but they will ship in subsequent minor releases (1.1, 1.2, etc.) as soon as they're ready.
I expect new additions will become part of the public API as soon as they get included in a tagged release. (Although this may be considered on a case by case basis.)
The Swift language hasn't stopped evolving, and we'd like this package to quickly embrace toolchain improvements that are relevant to its mandate. Accordingly, from time to time, we expect that new versions of this package will require clients to upgrade to the latest Swift toolchain release. (This allows the package to make use of new language/stdlib features, build on compiler bug fixes, and adopt new package manager functionality as soon as they are available.)
Requiring a new Swift release will only require a minor version bump.
The package manager's dependency resolution engine gracefully handles toolchain versioning, so people who are unable to upgrade their Swift toolchain will be able to continue using older package versions that did support them. We also have the option to support these older versions with back ported bug fixes.
Our expectation is that projects that would be interested in adopting new package features are, as a rule, also likely to upgrade to new toolchain releases. (Requiring a recent toolchain also reflects the reality that most engineering work on the package will be concentrated on targeting the latest Swift release (and development snapshots of the next one). Previous toolchain releases will receive limited testing at best.)
We have a list of changes we'd like to make before tagging 1.0, and we're officially soliciting feedback on these and for any other things you'd like to get changed -- please reply to this post with your comments!
The changes below will all be included in an upcoming 0.0.6 tag, including deprecations for APIs we intend to remove.
- Remove the dependency on the Swift Collections Benchmark package by moving the benchmark targets into a separate package, nested in a subdirectory of the same repository. (PR #86)
OrderedSet API updates: Follow the example of the standard
Set, and add an
index(of:)method, in addition to the
lastIndex(of:)methods we already have. (Issue #88)
OrderedDictionary API updates:
subscript(offset:)from the top-level
OrderedDictionarytype. (Issue #89)
This subscript uses inconsistent terminology (index vs offset), and it has a well-established, easy to use alternative in the
/* deprecated: */ d[offset: 2] // (key: "two", value: 2) /* replacement: */ d.elements // (key: "two", value: 2)
(Originally I wanted to also remove
index(forKey:); however, as a result of discussions below, I agreed it makes sense to keep it.)
OrderedDictionary.modifyValue(...)family of methods to
OrderedDictionary.updateValue(...), to better match the standard
Dictionary.updateValue. (Issue #90)