Skip to content

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Jul 24, 2025

Note

Mend has cancelled the proposed renaming of the Renovate GitHub app being renamed to mend[bot].

This notice will be removed on 2025-10-07.


This PR contains the following updates:

Package Update Change
apple/swift-collections minor from: "1.2.0" -> from: "1.3.0"

Release Notes

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

v1.3.0: Swift Collections 1.3.0

Compare Source

This feature release supports Swift toolchain versions 6.0, 6.1 and 6.2, and it includes the following improvements:

BasicContainers module

This new module collects ownership-aware, low-level variants of existing data structures in the core standard library. In this release, this module consists of two array variants, UniqueArray and RigidArray.

These new types are provided as less flexible, noncopyable alternatives to the classic Array type. The standard Array implements value semantics with the copy-on-write optimization; this inherently requires elements to be copyable, and it is itself copyable.

struct UniqueArray<Element> is a noncopyable array variant that takes away Array's copy-on-write behavior, enabling support for noncopyable elements. This type's noncopyability means mutations can always assume that the array is uniquely owned, with no shared copies (hence the name!). This means that array mutations such as mutating an element at an index can behave much more predictably, with no unexpected performance spikes due to having to copy shared storage.

struct RigidArray<Element> goes even further, by also disabling dynamic resizing. Rigid arrays have a fixed capacity: they are initialized with room for a particular number of elements, and they never implicitly grow (nor shrink) their storage. When a rigid array's count reaches its capacity, it becomes unable to add any new items -- inserting into a full array is considered a programming error. This makes this a quite inflexible (or rigid) type indeed, as avoiding storage overflow requires careful, up front planning on the resource needs of the task at hand. In exchange, rigid arrays can have extremely predictable performance characteristics.

UniqueArray is a great default choice when a task just needs an array type that is able store noncopyable elements. RigidArray is best reserved for use cases that require absolute, pedantic control over memory use or latency -- such as control software running in environments with extremely limited memory, or when a certain task must always be completed in some given amount of time.

The Unique and Rigid prefixes applied here establish a general naming convention for low-level variants of the classic copy-on-write data structure implementations. Future releases are expected to flesh out our zoo of container types by adding Unique and Rigid variants of the existing Set, Dictionary, Deque, Heap and other constructs, with type names such as as RigidDictionary and UniqueDeque.

TrailingElementsModule module

This new module ships a new TrailingArray construct, a preview of a new low-level, ownership-aware variant of ManagedBuffer. This is primarily intended as a interoperability helper for C constructs that consist of a fixed-size header directly followed by variable-size storage buffer.

ContainersPreview module

This module is intended to contain previews of an upcoming ownership-aware container model. In this initial release, this module consists of just one construct: struct Box<T>.

Box is a wrapper type that forms a noncopyable, heap allocated box around an arbitrary value.

What's Changed

New Contributors

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

v1.2.1: Swift Collections 1.2.1

Compare Source

This is a patch release with the following minor improvements:

  • BigString sometimes miscounted distances in its character view, resulting in an invalid collection conformance. This is now fixed. (#​485)
  • BigString's Unicode Scalar and character views now make better use of known lengths of the text chunks stored in the tree, resulting in significantly improved performance for their distance measurements. (#​486)
  • The Foundation-specific toolchain configuration was updated to include the Deque type. (#​496)

What's Changed

Full Changelog: apple/swift-collections@1.2.0...1.2.1


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 fa2d451 to 1244fce Compare September 29, 2025 18:39
@renovate renovate bot changed the title Update dependency apple/swift-collections to from: "1.2.1" Update dependency apple/swift-collections to from: "1.3.0" Sep 29, 2025
@renovate renovate bot force-pushed the renovate/apple-swift-collections-1.x branch from 1244fce to 4d226e5 Compare September 30, 2025 07:19
@renovate renovate bot force-pushed the renovate/apple-swift-collections-1.x branch from 4d226e5 to 4b62075 Compare October 1, 2025 19:09
@kishikawakatsumi kishikawakatsumi merged commit a3e1d7c into main Oct 1, 2025
1 check passed
@kishikawakatsumi kishikawakatsumi deleted the renovate/apple-swift-collections-1.x branch October 1, 2025 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant