Update dependency apple/swift-collections to from: "1.3.0" #19
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
from: "1.2.0"
->from: "1.3.0"
Release Notes
apple/swift-collections (apple/swift-collections)
v1.3.0
: Swift Collections 1.3.0Compare Source
This feature release supports Swift toolchain versions 6.0, 6.1 and 6.2, and it includes the following improvements:
BasicContainers
moduleThis 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
andRigidArray
.These new types are provided as less flexible, noncopyable alternatives to the classic
Array
type. The standardArray
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 awayArray
'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
andRigid
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 addingUnique
andRigid
variants of the existingSet
,Dictionary
,Deque
,Heap
and other constructs, with type names such as asRigidDictionary
andUniqueDeque
.TrailingElementsModule
moduleThis new module ships a new
TrailingArray
construct, a preview of a new low-level, ownership-aware variant ofManagedBuffer
. 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
moduleThis 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
release/1.1
tomain
by @lorentey in #248release/1.1
tomain
by @lorentey in #358OrderedSet.appending(contentsOf:)
by @pm-dev in #452SortedCollections
module by @lorentey in #479release/1.2
tomain
branch by @lorentey in #487release/1.2
by @cthielen in #498pull_request.yml
by @MaxDesiatov in #509Box
,RigidArray
,DynamicArray
by @lorentey in #508arch
sub-folder by @Steelskin in #505New Contributors
Full Changelog: apple/swift-collections@1.2.1...1.3.0
v1.2.1
: Swift Collections 1.2.1Compare 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)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.
This PR was generated by Mend Renovate. View the repository job log.