Bump github.com/apple/swift-collections from 1.3.0 to 1.4.0

[dependabot]

Bumps github.com/apple/swift-collections from 1.3.0 to 1.4.0.

Release notes

Sourced from github.com/apple/swift-collections's releases.

Swift Collections 1.4.0

This feature release supports Swift toolchain versions 6.0, 6.1 and 6.2. It includes a variety of bug fixes, and ships the following new features:

New ownership-aware ring buffer and hashed container implementations

In the DequeModule module, we have two new source-stable types that provide ownership-aware ring buffer implementations:

• struct UniqueDeque<Element> is a uniquely held, dynamically resizing, noncopyable deque.
• struct RigidDeque<Element> is a fixed-capacity deque implementation.

RigidDeque/UniqueDeque are to Deque like RigidArray/UniqueArray are to Array -- they provide noncopyable embodiments of the same basic data structure, with many of the same operations.

In the BasicContainers module, this release adds previews of four new types, implementing ownership-aware hashed containers:

• struct UniqueSet<Element> is a uniquely held, dynamically resizing set.
• struct RigidSet<Element> is a fixed-capacity set.
• struct UniqueDictionary<Key, Value> is a uniquely held, dynamically resizing dictionary.
• struct RigidDictionary<Key, Value> is a fixed-capacity dictionary.

These are direct analogues of the standard Set and Dictionary types. These types are built on top of the Equatable and Hashable protocol generalizations that were proposed in SE-0499; as that proposal is not yet implemented in any shipping toolchain, these new types are shipping as source-unstable previews, conditional on a new UnstableHashedContainers package trait. The final API of these types will also deeply depend on the struct Borrow and struct Inout proposals (and potentially other language/stdlib improvements) that are currently working their way through the Swift Evolution process. Accordingly, we may need to make source-breaking changes to the interfaces of these types -- they are not ready to be blessed as Public API. However, we encourage intrepid engineers to try them on for size, and report pain points. (Of which we expect there will be many in this first preview.)

We continue the pattern of Rigid- and Unique- naming prefixes with these new types:

• The Unique types (UniqueArray, UniqueDeque, UniqueSet, UniqueDictionary etc.) are dynamically self-sizing containers that automatically reallocate their storage as needed to best accommodate their contents; the Unique prefix was chosen to highlight that these types are always uniquely held, avoiding the complications of mutating shared copies.
• The Rigid types remove dynamic sizing, and they operate strictly within an explicitly configured capacity. Dynamic sizing is not always appropriate -- when targeting space- or time-constrained environments (think embedded use cases or real-time work), it is preferable to avoid implicit reallocations, and to instead choose to have explicit control over when (and if) storage is reallocated, and to what size. This is where the Rigid types come in: their instances are created with a specific capacity and it is a runtime error to exceed that. This makes them quite inflexible (hence the "rigid" qualifier), but in exchange, their operations provide far stricter complexity guarantees: they exhibit no random runtime latency spikes, and they can trivially fit in strict memory budgets.

Early drafts of borrowing sequence, generative iteration and container protocols

This release includes highly experimental but working implementations of new protocols supplying ownership-aware alternatives to the classic Sequence/Collection protocol hierarchy. These protocols and the generic operations built on top of them can be turned on by enabling the UnstableContainersPreview package trait.

• protocol BorrowingSequence<Element> models borrowing sequences with ephemeral lifetimes. (This is already progressing through Swift Evolution.)
• protocol Container<Element> models constructs that physically store their contents, and can expose stable spans over them.
• protocol Producer<Element, ProducerError> models a generative iterator -- a construct that generates items demand.
• protocol Drain<Element> refines Producer to model an in-place consumable elements -- primarily for use around container types.

In this version, the package has developed these protocols just enough to implement basic generic operations for moving data between containers like UniqueArray and RigidDeque. As we gain experience using these, future releases may start adding basic generic algorithms, more protocols (bidirectional, random-access, (per)mutable, range-replaceable containers etc.) convenience adapters, and other features -- or we may end up entirely overhauling or simply discarding some/all of them. Accordingly, the experimental interfaces enabled by UnstableContainersPreview are not source stable, and they are not intended for production use. We expect the eventual production version of these (or whatever designs they evolve into) to ship in the Swift Standard Library. We do highly recommend interested folks to try playing with these, to get a feel for the strange problems of Ownership.

... (truncated)

Commits

• 8d9834a Merge pull request #590 from lorentey/prerelease-tasks
• 94e8cab [BasicContainers] RigidArray: Correct spelling of replacement for deprecated ...
• d5711fe Merge pull request #589 from lorentey/prerelease-tasks
• 5605e14 [BasicContainers] Avoid defining set/dictionary types unless UnstableHashedCo...
• 49d0082 Merge pull request #588 from lorentey/prerelease-tasks
• 1c69635 Add SPDX-License-Identifier tags
• d4722f4 [tests] Adjust visibility of API checker protocols
• 11a4966 [Benchmarks] Update benchmarking sub-package
• d9b09ec Update copyright dates
• 334dcb0 Merge pull request #587 from lorentey/update-readme
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud