Skip to content

Update dependency apple/swift-collections to from: "1.4.1"#24

Merged
kishikawakatsumi merged 1 commit intomainfrom
renovate/apple-swift-collections-1.x
Mar 29, 2026
Merged

Update dependency apple/swift-collections to from: "1.4.1"#24
kishikawakatsumi merged 1 commit intomainfrom
renovate/apple-swift-collections-1.x

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate bot commented Mar 7, 2026 •
edited
Loading

This PR contains the following updates:

Package Update Change
apple/swift-collections minor from: "1.3.0" → from: "1.4.1"

Release Notes

apple/swift-collections (apple/swift-collections)

v1.4.1: Swift Collections 1.4.1

Compare Source

This patch release is mostly focusing on evolving the package traits UnstableContainersPreview and UnstableHashedContainers, with the following notable fixes and improvements to the stable parts of the package:

  • Make the package documentation build successfully on the DocC that ships in Swift 6.2.
  • Avoid using floating point arithmetic to size collection storage in the DequeModule and OrderedCollections modules.

Changes to experimental package traits

The new set and dictionary types enabled by the UnstableHashedContainers trait have now resolved several correctness issues in their implementation of insertions. They have also gained some low-hanging performance optimizations. Like before, these types are in "working prototype" phase, and while they have working implementations of basic primitive operations, we haven't done much work validating their performance yet. Feedback from intrepid early adopters would be very welcome.

The UnstableContainersPreview trait has gained several new protocols and algorithm implementations, working towards one possible working model of a coherent, ownership-aware container/iteration model.

  • BidirectionalContainer defines a container that allows iterating over spans backwards, and provides decrement operations on indices -- an analogue of the classic BidirectionalCollection protocol.
  • RandomAccessContainer models containers that allow constant-time repositioning of their indices, like RandomAccessCollection.
  • MutableContainer is the ownership-aware analogue of MutableCollection -- it models a container type that allows its elements to be arbitrarily reordered and mutated/reassigned without changing the shape of the data structure (that is to say, without invalidating any indices).
  • PermutableContainer is an experimental new spinoff of MutableContainer, focusing on reordering items without allowing arbitrary mutations.
  • RangeReplaceableContainer is a partial, ownership-aware analogue of RangeReplaceableCollection, providing a full set of insertion/append/removal/consumption operations, with support for fixed-capacity conforming types.
  • DynamicContainer rounds out the range-replacement operations with initializer and capacity reservation requirements that can only be implemented by dynamically sized containers.
  • We now have working reference implementations of lazy map, reduce and filter operations on borrowing iterators, producers and drains, as well a collect(into:) family of methods to supply "greedy" variants, generating items into a container of the user's choice. Importantly, the algorithms tend to be defined on the iterator types, rather than directly on some sequence/container -- going this way has some interesting benefits (explicitness, no confusion between the various flavors or the existing Sequence algorithms), but they also have notable drawbacks (minor design issues with the borrowing iterator protocol, unknowns on how the pattern would apply to container algorithms, etc.).
    let items: RigidArray<Int> = ...
    let transformed = 
      items.makeBorrowingIterator() // obviously we'd want a better name here, like `borrow()`
      .map { 2 * $0 }
      .collect(into: UniqueArray.self)
    // `transformed` is a UniqueArray instance holding all values in `items`, doubled up 
    let items: RigidArray = ...
    let transformed = 
       items.makeBorrowingIterator()
      .filter { !$0.isMultiple(of: 7) }
      .copy()
      .collect(into: UniqueArray.self)
    // `transformed` holds a copy of all values in `items` that aren't a multiple of 7
    let items: RigidArray = ...
    let transformed = 
       items.consumeAll()
      .filter { !$0.isMultiple(of: 7) }
      .collect(into: UniqueArray.self)
    // `transformed` holds all values that were previously in `items` that aren't a multiple of 7. `items` is now empty.

Like before, these are highly experimental, and they will definitely change in dramatic/radical ways on the way to stabilization. Note that there is no project- or team-wide consensus on any of these constructs. I'm publishing them primarily as a crucial reference point, and to gain a level of shared understanding of the actual problems that need to be resolved, and the consequences of the design path we are on.

What's Changed

New Contributors

Full Changelog: apple/swift-collections@1.4.0...1.4.1

v1.4.0: Swift Collections 1.4.0

Compare Source

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:

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:

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.

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.

Besides these protocols, the package also defines rudimentary substitutes of some basic primitives that belong in the Standard Library:

  • struct InputSpan<Element> the dual of OutputSpan -- while OutputSpan is primarily for moving items into somebody else's storage, InputSpan enables safely moving items out of storage.
  • struct Borrow<Target> represents a borrowing reference to an item. (This package models this with a pointer, which is an ill-fitting substitute for the real implementation in the stdlib.)
  • struct Inout<Target> represents a mutating reference to an item.
A formal way to access SortedSet and SortedDictionary types

The SortedCollections module contains (preexisting) early drafts of two sorted collection types SortedSet and SortedDictionary, built on top of an in-memory B-tree implementation. This release defines an UnstableSortedCollections package trait that can be used to enable building these types for experimentation without manually modifying the package. Like in previous releases, these implementations remain unfinished in this release, with known API issues; accordingly, these types remain unstable. (Issue #​1 remains open.) Future package releases may change their interface in ways that break source compatibility, or they may remove these types altogether.

Minor interface-level changes

  • The Collections module no longer uses the unstable @_exported import feature. Instead, it publishes public typealiases of every type that it previously reexported from DequeModule, OrderedCollections, BitCollections, HeapModule and HashTreeCollections.

  • We renamed some RigidArray/UniqueArray operations to improve their clarity at the point of use. The old names are still available, but deprecated.

    Old name New name
    append(count:initializingWith:) append(addingCount:initializingWith:)
    insert(count:at:initializingWith:) insert(addingCount:at:initializingWith:)
    replaceSubrange(_:newCount:initializingWith:) replace(removing:addingCount:initializingWith:)
    replaceSubrange(_:moving:) replace(removing:moving:)
    replaceSubrange(_:copying:) replace(removing:copying:)
    copy() clone()
    copy(capacity:) clone(capacity:)

  • We have now defined a complete set of OutputSpan/InputSpan-based append/insert/replace/consume primitives, fully generalized to be implementable by piecewise contiguous containers. These operations pave the way for a Container-based analogue of the classic RangeReplaceableCollection protocol, with most of the user-facing operations becoming standard generic algorithms built on top of these primitives:

    mutating func append<E: Error>(
    addingCount newItemCount: Int,
    initializingWith initializer: (inout OutputSpan<Element>) throws(E) -> Void
)

mutating func insert<E: Error>(
   addingCount newItemCount: Int,
   at index: Int,
   initializingWith initializer: (inout OutputSpan<Element>) throws(E) -> Void
) throws(E)

mutating func replace<E: Error>(
    removing subrange: Range<Int>,
    consumingWith consumer: (inout InputSpan<Element>) -> Void,
    addingCount newItemCount: Int,
    initializingWith initializer: (inout OutputSpan<Element>) throws(E) -> Void
) throws(E)

mutating func consume(
    _ subrange: Range<Int>,
    consumingWith consumer: (inout InputSpan<Element>) -> Void
)

  • The package no longer uses the code generation tool gyb.

What's Changed

New Contributors

Full Changelog: apple/swift-collections@1.3.0...1.4.0

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot force-pushed the renovate/apple-swift-collections-1.x branch from e54b11d to 78ebb14 Compare March 17, 2026 20:47
@renovate renovate bot force-pushed the renovate/apple-swift-collections-1.x branch from 78ebb14 to 8888ebb Compare March 19, 2026 01:11
@renovate renovate bot changed the title Update dependency apple/swift-collections to from: "1.4.0" Update dependency apple/swift-collections to from: "1.4.1" Mar 19, 2026
@kishikawakatsumi kishikawakatsumi merged commit ffa869c into main Mar 29, 2026
1 check passed
@kishikawakatsumi kishikawakatsumi deleted the renovate/apple-swift-collections-1.x branch March 29, 2026 23:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@kishikawakatsumi