You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+12-11Lines changed: 12 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,10 +10,6 @@ Read more about the package, and the intent behind it, in the [announcement on s
10
10
11
11
The package currently provides the following implementations:
12
12
13
-
-[`UniqueArray`][UniqueArray], a dynamically self-resizing, heap allocated, noncopyable array of potentially noncopyable elements.
14
-
15
-
-[`RigidArray`][RigidArray], a fixed capacity, heap allocated, noncopyable array of potentially noncopyable elements.
16
-
17
13
-[`BitSet`][BitSet] and [`BitArray`][BitArray], dynamic bit collections.
18
14
19
15
-[`Deque<Element>`][Deque], a double-ended queue backed by a ring buffer. Deques are range-replaceable, mutable, random-access collections.
@@ -26,8 +22,10 @@ The package currently provides the following implementations:
26
22
27
23
-[`TreeSet`][TreeSet] and [`TreeDictionary`][TreeDictionary], persistent hashed collections implementing Compressed Hash-Array Mapped Prefix Trees (CHAMP). These work similar to the standard `Set` and `Dictionary`, but they excel at use cases that mutate shared copies, offering dramatic memory savings and radical time improvements.
-[`UniqueArray`][UniqueArray] and [`RigidArray`][RigidArray], noncopyable array variants trading some of `Array`'s flexibility for more predictable performance.
26
+
27
+
-[`TrailingArray`][TrailingArray], a low-level, ownership-aware variant of `ManagedBuffer`, for interoperability with C constructs that consist of a fixed-size header directly followed by variable-size storage buffer.
Swift Collections uses the same modularization approach as [**Swift Numerics**](https://github.com/apple/swift-numerics): it provides a standalone module for each thematic group of data structures it implements. For instance, if you only need a double-ended queue type, you can pull in only that by importing `DequeModule`. `OrderedSet` and `OrderedDictionary` share much of the same underlying implementation, so they are provided by a single module, called `OrderedCollections`. However, there is also a top-level `Collections` module that gives you every collection type with a single import statement:
41
+
Swift Collections uses the same modularization approach as [**Swift Numerics**](https://github.com/apple/swift-numerics): it provides a standalone module for each thematic group of data structures it implements. For instance, if you only need a double-ended queue type, you can pull in only that by importing `DequeModule`. `OrderedSet` and `OrderedDictionary` share much of the same underlying implementation, so they are provided by a single module, called `OrderedCollections`. However, there is also a top-level `Collections` module that gives you the most commonly used collection types with a single import statement:
41
42
42
43
```swift
43
44
importCollections
@@ -95,7 +96,7 @@ The following table maps package releases to their minimum required Swift toolch
95
96
To use this package in a SwiftPM project, you need to set it up as a package dependency:
96
97
97
98
```swift
98
-
// swift-tools-version:6.1
99
+
// swift-tools-version:6.2
99
100
importPackageDescription
100
101
101
102
letpackage=Package(
@@ -132,14 +133,14 @@ We maintain separate branches for each minor version of the package:
| swift-collections 1.2.x | release/1.2 |Bugfixes only |
137
138
| swift-collections 1.3.x | release/1.3 | Bugfixes only |
138
139
| n.a. | main | Feature work towards next minor release |
139
140
140
141
Changes must land on the branch corresponding to the earliest release that they will need to ship on. They are periodically propagated to subsequent branches, in the following direction:
For example, anything landing on `release/1.2` will eventually appear on `release/1.3` and then `main` too; there is no need to file standalone PRs for each release line. Change propagation is not instantaneous, as it currently requires manual work -- it is performed by project maintainers.
Copy file name to clipboardExpand all lines: Sources/BasicContainers/BasicContainers.docc/BasicContainers.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ This currently consists of two noncopyable variants of the standard `Array` type
8
8
9
9
Unlike `Array`, these new types do not support copy-on-write value semantics -- indeed, they aren't (implicitly) copyable at all, even if their element type happens to be copyable.
10
10
11
-
### `struct UniqueArray`
11
+
### struct UniqueArray
12
12
13
13
``UniqueArray`` is a dynamically self-resizing array type that automatically grows its storage as needed to accommodate inserted items. Its name highlights that unlike `Array`, instances of this type are always uniquely owned, never shared. Mutations of a `UniqueArray` therefore never need to copy their storage.
14
14
@@ -41,7 +41,7 @@ Note how preserving a copy of the array at the start of the loop forces the subs
41
41
42
42
Taking away the freedom to make implicit copies forces you to think a lot more about ownership concerns when using this type -- it can feel a lot more constrained and nitpicky. In exchange though, it gets much easier to reason about the runtime performance of your code; the subscript mutation looks the same as before, but now it is guaranteed to _always_ have constant complexity.
43
43
44
-
### `struct RigidArray`
44
+
### struct RigidArray
45
45
46
46
``RigidArray`` goes a step even further than ``UniqueArray`` by also disabling automatic storage reallocations: it is a fixed-capacity array type. Rigid array instances get created with a specific capacity, and they never resize themselves. If they run out of room, they report a runtime error!
47
47
@@ -62,7 +62,7 @@ This allows ``RigidArray`` to still provide _explicit_ resizing operations: it h
Copy file name to clipboardExpand all lines: Sources/Collections/Collections.docc/Collections.md
+9-10Lines changed: 9 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,18 +4,17 @@
4
4
5
5
## Overview
6
6
7
+
### Modules
7
8
9
+
-[**Basic Containers**](./basiccontainers) - Defines [`UniqueArray`][UniqueArray] and [`RigidArray`][RigidArray], noncopyable array variants trading some of `Array`'s flexibility for more predictable performance.
10
+
-[**Bit Collections**](./bitcollections) - Defines [`BitSet`](./bitcollections/bitset) and [`BitArray`](./bitcollections/bitarray), dynamic bit collections.
11
+
-[**Deque Module**](./dequemodule) - Defines [`Deque<Element>`](./dequemodule/deque), a double-ended queue backed by a ring buffer. Deques are range-replaceable, mutable, random-access collections.
12
+
-[**Heap Module**](./heapmodule) - Defines [`Heap`](./heapmodule/heap), a min-max heap backed by an array, suitable for use as a priority queue.
13
+
-[**Ordered Collections**](./orderedcollections) - Defines [`OrderedSet<Element>`](./orderedcollections/orderedset), a variant of the standard `Set` where the order of items is well-defined and items can be arbitrarily reordered. Uses a `ContiguousArray` as its backing store, augmented by a separate hash table of bit packed offsets into it. [`OrderedDictionary<Key, Value>`](./orderedcollections/ordereddictionary), an ordered variant of the standard `Dictionary`, providing similar benefits.
14
+
-[**Hash Tree Collections**](./hashtreecollections) - Defines [`TreeSet`](./hashtreecollections/treeset) and [`TreeDictionary`](./hashtreecollections/treedictionary), persistent hashed collections implementing Compressed Hash-Array Mapped Prefix Trees (CHAMP). These work similar to the standard `Set` and `Dictionary`, but they excel at use cases that mutate shared copies, offering dramatic memory savings and radical time improvements.
15
+
-[**Trailing Elements Module**](./trailingelementsmodule) - Defines [`TrailingArray`](./trailingarray), a low-level, ownership-aware variant of `ManagedBuffer`, for interoperability with C constructs that consist of a fixed-size header directly followed by variable-size storage buffer.
8
16
9
-
####Additional Resources
17
+
### Additional Resources
10
18
11
19
-[`Swift Collections` on GitHub](https://github.com/apple/swift-collections/)
12
20
-[`Swift Collections` on the Swift Forums](https://forums.swift.org/c/related-projects/collections/72)
13
-
14
-
### Modules
15
-
16
-
-[Basic Containers](./basiccontainers) - [`RigidArray`](./basiccontainers/rigidarray), a fixed capacity and no implicit resizing dynamic non-copyable array capable of storing non-copyable elements. [`UniqueArray`](./basiccontainers/uniquearray), an implicitly resizable dynamic non-copyable array capable of storing non-copyable elements.
17
-
-[Bit Collections](./bitcollections) - [`BitSet`](./bitcollections/bitset) and [`BitArray`](./bitcollections/bitarray), dynamic bit collections.
18
-
-[Deque Module](./dequemodule) - [`Deque<Element>`](./dequemodule/deque), a double-ended queue backed by a ring buffer. Deques are range-replaceable, mutable, random-access collections.
19
-
-[Heap Module](./heapmodule) - [`Heap`](./heapmodule/heap), a min-max heap backed by an array, suitable for use as a priority queue.
20
-
-[Ordered Collections](./orderedcollections) - [`OrderedSet<Element>`](./orderedcollections/orderedset), a variant of the standard `Set` where the order of items is well-defined and items can be arbitrarily reordered. Uses a `ContiguousArray` as its backing store, augmented by a separate hash table of bit packed offsets into it. [`OrderedDictionary<Key, Value>`](./orderedcollections/ordereddictionary), an ordered variant of the standard `Dictionary`, providing similar benefits.
21
-
-[Hash Tree Collections](./hashtreecollections) - [`TreeSet`](./hashtreecollections/treeset) and [`TreeDictionary`](./hashtreecollections/treedictionary), persistent hashed collections implementing Compressed Hash-Array Mapped Prefix Trees (CHAMP). These work similar to the standard `Set` and `Dictionary`, but they excel at use cases that mutate shared copies, offering dramatic memory savings and radical time improvements.
0 commit comments