]> git.proxmox.com Git - rustc.git/blob - vendor/im-rc/CHANGELOG.md
New upstream version 1.70.0+dfsg2
[rustc.git] / vendor / im-rc / CHANGELOG.md
1 # Changelog
2
3 All notable changes to this project will be documented in this file.
4
5 The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) and this project
6 adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
7
8 ## [15.1.0] - 2022-04-29
9
10 ### Added
11
12 - `HashSet` now implements `From<Vector<A>>` and `From<&Vector<A>> where A: Clone`.
13
14 ### Fixed
15
16 - Fixed a long standing crash bug in `OrdMap`/`OrdSet`. (#154, #143, #152, #124)
17 - The `union` method on maps/sets will now prefer to mutate the larger set (which leads to less
18 work) rather than the first set. (#163)
19 - Ensure `TreeFocus` only implements `Send`/`Sync` when the underlying type does. (#157, #158)
20 - There was an issue where nodes in very large `OrdMap`s could overflow when removing an element
21 and cause a panic, which has now been fixed. (#141)
22 - Assorted doc cleanup. (#150, #173, #186, #194)
23
24 ## [15.0.0] - 2020-05-15
25
26 ### Changed
27
28 - Map iterators now return `(&K, &V)` and `(&K, &mut V)` respectively, to be consistent with
29 `std::collections`'s API. `DiffIter` for `OrdMap` has also changed in the same manner. (#121)
30
31 ### Removed
32
33 - The `pool` feature flag has been removed from the `im` version of the crate, as `refpool` no
34 longer supports threadsafe pools.
35 - `HashSet::iter_mut()` has been removed, because if you modify the hashed values in a hash set,
36 you break the hash set.
37
38 ### Added
39
40 - The `pool` feature flag was missing from the `im-rc` version of the crate, which is the version
41 where it's actually useful. It's been added now.
42 - `DiffIter` now has a `Debug` implementation.
43 - There is now a `Vector::is_inline()` method to determine whether a `Vector` is currently
44 inlined. (#129)
45
46 ### Fixed
47
48 - A smarter implementation of the sorting algorithm for `Vector` has improved the performance of
49 `Vector::sort` by approximately 2x. (#126)
50
51 ## [14.3.0] - 2020-03-03
52
53 ### Changed
54
55 - `proptest` strategies have been moved to `im::proptest`. The previous locations of the
56 strategies (`im::vector::proptest` etc) are still available, but have been deprecated.
57
58 ### Added
59
60 - `OrdSet` and `OrdMap` now have `get_prev` and `get_next` methods (with equivalent `get_prev_mut`
61 and `get_next_mut` methods for `OrdMap`) which will return the closest key match to the
62 requested key in the specified direction if the key isn't in the set. (#95)
63 - The `retain` method, inexplicably missing from `HashMap` but not `HashSet`, has been added.
64 (#120)
65 - The `get_mut` method on `OrdMap` was, equally inexplicably, private. It has now been made
66 public.
67
68 ## [14.2.0] - 2020-01-17
69
70 ### Added
71
72 - Both map types now have the `get_key_value()` method, corresponding to the equivalent
73 [additions](https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.get_key_value)
74 to the standard library.
75 - The `ptr_eq` method has been added to all data types, allowing you to test whether two values
76 refer to the same content in memory, by testing for pointer equality. (#117)
77 - `HashMap` had lost its `Arbitrary` implementation for the `quickcheck` feature flag. It's now
78 been restored. (#118)
79 - Implementations for `Arbitrary` from the [`arbitrary`](https://crates.io/crates/arbitrary/)
80 crate have been added behind the `arbitrary` feature flag.
81
82 ### Fixed
83
84 - Fixed a bug when reversing a consuming iterator over a `Vector` by replacing the consuming
85 iterator with a much simpler and slightly more efficient version. (#116)
86
87 ## [14.1.0] - 2019-12-16
88
89 ### Added
90
91 - If you enable the `pool` feature flag, im now supports constructing data types using
92 [`refpool`](https://crates.io/crates/refpool) to speed up chunk allocation. The performance
93 boost will vary between use cases and operating systems, but generally at least a 10% speedup
94 can be expected when constructing a data type from an iterator, and the more complex an
95 operation is, the more likely it is to benefit from being able to quickly reallocate chunks.
96 Note that in order to use this feature, you have to construct your data types using the
97 `with_pool(&pool)` constructor, it's not enough just to enable the feature flag.
98
99 ## [14.0.0] - 2019-11-19
100
101 ### Changed
102
103 - As `sized-chunks` now requires a slightly more recent version of `rustc` to compile,
104 specifically version 1.36.0, so does `im`. This is a breaking change, but will of course only
105 affect your code if you're using an older `rustc`.
106
107 ### Fixed
108
109 - Fixed a quadratic time worst case scenario in the quicksort implementation for `Vector`. (#101)
110 - Fixed an edge case bug when splitting and joining large `Vector`s. (#105, #107)
111
112 ## [13.0.0] - 2019-05-18
113
114 The minimum supported Rust version is now 1.34.0.
115
116 ### Changed
117
118 - `im::iter::unfold` now gives you the owned state value rather than an immutable reference to it,
119 which makes it a little more useful.
120
121 ### Removed
122
123 - The deprecated `singleton` constructors have been removed. Please use `unit` instead.
124 - The deprecated methods `Vector::chunks` and `Vector::chunks_mut` have been removed in favour of
125 `Vector::leaves` and `Vector::leaves_mut` respectively. (#50)
126 - The deprecated reference to [`sized-chunks`](https://crates.io/crates/sized-chunks) has been
127 removed. If you need it, please use the `sized-chunks` crate directly.
128 - `im::iter::unfold_mut` has been removed, as there's no meaningful difference between it and
129 rust-std 1.34.0's `std::iter::from_fn` with a captured state variable.
130
131 ### Fixed
132
133 - `Vector` now uses
134 [`sized_chunks::InlineArray`](https://docs.rs/sized-chunks/0.3.0/sized_chunks/inline_array/struct.InlineArray.html)
135 instead of an `Empty` enum case to avoid allocation at very small sizes, letting you store a
136 handful of elements on the stack before needing to grow into a full chunk. This has a beneficial
137 effect on performance as well, as there's no pointer into the heap to dereference, making it
138 faster than `std::vec::Vec` in this configuration.
139 - Some complexity timings have been added and corrected. (#87)
140 - `OrdSet::is_subset(&self, other)` now returns immediately when `self` is larger than `other` and
141 thus could not possibly be a subset of it. (#87)
142
143 ## [12.3.4] - 2019-04-08
144
145 ### Changed
146
147 - `Clone` constraints have been further relaxed on maps and sets, so that you can now lookup and
148 iterate over them without requiring a `Clone` constraint (though you do still need `Clone` to
149 actually insert data into them to lookup or iterate over). (#81)
150
151 ### Fixed
152
153 - Enforces the latest bugfix release of sized-chunks. (#78)
154 - Another edge case bugfix to `Vector`'s size table handling. (#79)
155
156 ## [12.3.3] - 2019-03-11
157
158 ### Fixed
159
160 - A number of issues were fixed where `Vector`'s size table would get out of sync with the node
161 structure if exercised too much and cause erroneous behaviour. (#72, #74)
162 - Comprehensive generative tests were added to test all data structures through more unexpected
163 code paths.
164
165 ## [12.3.2] - 2019-03-05
166
167 ### Changed
168
169 - `Clone` constraints on all data structures, as well as relevant constraints on maps and sets,
170 have been relaxed where possible, so that you can now construct empty instances and call most
171 query methods without requiring values implement `Clone` etc. (#63)
172
173 ### Fixed
174
175 - Constructing an empty `Vector` will not allocate any heap memory, instead deferring allocation
176 until you perform an operation that would increase its length. (#65)
177 - Some bugs arising when using `Vector::append` repeatedly were fixed. (#67, #70)
178
179 ## [12.3.1] - 2019-02-19
180
181 ### Changed
182
183 - Unsafe chunks have been separated out into the `sized-chunks` crate, which is now a dependency
184 of `im`.
185
186 ## [12.3.0] - 2019-01-15
187
188 ### Added
189
190 - `singleton` methods have been deprecated and renamed to `unit`.
191 - `Vector::chunks` and `Vector::chunks_mut` have been deprecated and renamed to `leaves` and
192 `leaves_mut` to avoid confusion with `Vec::chunks`. (#50)
193
194 ### Fixed
195
196 - Fixed an issue where the `HashMap` draining iterator might access uninitialised memory leading
197 to undefined behaviour. (#60)
198 - Fixed multiple issues in `Vector::split_off` and `Vector::append` that would cause lookup errors
199 and unexpectedly unbalanced trees. (#55).
200
201 ## [12.2.0] - 2018-10-12
202
203 ### Added
204
205 - `OrdMap` and `OrdSet` now have a `range()` method which makes an iterator over a bounded subset
206 of the values. The improved iterator implementation is also considerably more efficient than the
207 previous (about an order of magnitude faster for nontrivial data sets). `iter()` has been
208 updated to take advantage of this, and is now just an alias for `range(..)`. (#27)
209 - `FocusMut` now has an `unmut` method to turn it into an immutable `Focus`, releasing its
210 exclusive hold on the underlying `Vector`.
211 - `Focus` now implements `Clone`.
212
213 ## [12.1.0] - 2018-09-25
214
215 ### Added
216
217 - Maps and sets now have the `clear` method just like `Vector`. (#46)
218
219 ### Changed
220
221 - Single chunk `Vector`s are no longer allocated directly on the stack, meaning that they're now
222 comparable in performance to `std::vec::Vec` rather than slightly faster, but they also won't
223 eat up your stack space quite as quickly, and they'll clone without copying and share structure
224 with clones as you'd expect.
225
226 ## [12.0.0] - 2018-08-30
227
228 Starting with this release, the `arc` flag is gone, in favour of publishing `im` as two separate
229 crates: `im` (using `Arc`) and `im-rc` (using `Rc`). They're identical (and built from the same
230 code), except that `im` is thread safe and `im-rc` is a little bit more performant.
231
232 This is a major release as a consequence, but there should be no breaking code changes other than
233 the new default choice of reference counter.
234
235 ### Added
236
237 - The `Chunk` datatype that's used to build `Vector` and `OrdMap` has been exposed and made
238 generally usable. It's somewhere between a
239 [`GenericArray`](https://crates.io/crates/generic-array) and a ring buffer, offers O(1)\* push
240 in either direction, and is generally hyperoptimised for its purpose of serving as nodes for
241 Bagwell tries, but it's also a powered up version of
242 [`GenericArray`](https://crates.io/crates/generic-array) that might be useful to others, hence
243 the public API.
244 - `Vector` now has `Focus` and `FocusMut` APIs for caching index lookups, yielding huge
245 performance gains when performing multiple adjacent index lookups. `Vector::iter` has been
246 reimplemented using this API, and is now much simpler and about twice as fast as a result, and
247 `Vector::iter_mut` now runs nearly an order of magnitude faster. Likewise, `Vector::sort` and
248 `Vector::retain` are now using `FocusMut` and run considerably faster as a result.
249 - `Focus` and `FocusMut` can also be used as stand ins for subslices through the `narrow` and
250 `split_at` methods. You can also iterate over foci, making this the most efficient way to
251 iterate over a subset of a `Vector`.
252 - `Vector` now implements [Rayon](https://crates.io/crates/rayon)'s parallel iterators behind the
253 `rayon` feature flag.
254
255 ### Changed
256
257 - As `std::ops::RangeBounds` is now stabilised in Rust 1.28, the `Vector::slice` method is now
258 unconditionally available on the stable channel.
259 - Union/difference/intersection/is_submap methods on `HashMap` and `OrdMap` that take functions
260 now take `FnMut` instead of `Fn`. This should not affect any existing code. (#34)
261 - `Vector::split_off` can now take an index equal to the length of the vector, yielding an empty
262 vector as the split result. (#33)
263 - `Vector::set` now returns the replaced value.
264
265 ### Fixed
266
267 - `Vector` is now represented as a single inline chunk until it grows larger than the chunk size,
268 making it even faster than `Vec` at small sizes, though `clone` could now be slower if the clone
269 is expensive (it's still absurdly fast for `A: Copy`).
270
271 ## [11.0.1] - 2018-07-23
272
273 ### Fixed
274
275 - Various performance improvements, amounting to a 5-10% speedup for both kinds of map/set.
276 - Fixed an edge case bug in `sort::quicksort`.
277
278 ## [11.0.0] - 2018-07-10
279
280 ### Changed
281
282 This is a major release with many breaking changes, and is intended to stabilise the API more than
283 to denote that the rewrite is now production ready. You should expect future releases with
284 significant performance improvements as well as additional APIs, but there should be no further
285 major release with breaking changes in the immediate future, barring very serious unforeseen issues.
286
287 Specifically, you should expect imminent minor releases with performance improvements for `Vector`
288 and `OrdMap`, for which I have a number of known optimisations that remain unimplemented.
289
290 #### No More `Arc`
291
292 All data structures have been reworked to take values of `A: Clone` instead of `Arc<A>`, meaning
293 that there's less performance overhead (as well as mental overhead) when using values that clone
294 cheaply. The performance gain when values are `A: Copy` is a factor of two or more. It's expected
295 that users should wrap values in `Arc` themselves when using values which are expensive to clone.
296
297 Data structures still use reference counters internally to reference nodes, but values are stored
298 directly in the nodes with no further indirection. This is also good for cache locality.
299
300 Data structures now use `Rc` instead of `Arc` by default to do reference counting. If you need a
301 thread safe version that implements `Send` and `Sync`, you can enable the `arc` feature on the
302 package to compile with `Arc` instead.
303
304 #### `std::collections` Compatible API
305
306 The API has been reworked to align more closely with `std::collections`, favouring mutable
307 operations by default, so that operations that were previously suffixed with `_mut` are now the
308 standard operations, and immutable operations which return a modified copy have been given different
309 names altogether. In short, all your code using previous versions of this library will no longer
310 work, and if it was relying heavily on immutable operations, it's recommended that you rewrite it to
311 be mutable by preference, but you should generally be able to make it work again by using the new
312 method names for the immutable operations.
313
314 Here is a list of the most notable changed method names for maps and sets:
315
316 | Previous immutable | Current immutable | Previous mutable | Current mutable |
317 | ------------------ | ----------------- | ---------------- | --------------- |
318 | `insert` | `update` | `insert_mut` | `insert` |
319 | `remove` | `without` | `remove_mut` | `remove` |
320 | `pop` | `extract` | `pop_mut` | `remove` |
321
322 You should expect to be able to rewrite code using `std::collections::HashMap` and
323 `std::collections::BTreeMap` with minimal or no changes using `im::HashMap` and `im::OrdMap`
324 respectively.
325
326 `Vector` has been completely rewritten and has an API that aligns closely with
327 `std::collections::VecDeque`, with very few immutable equivalents. It's expected that you should use
328 `Vector::clone()` to take a snapshot when you need it rather than cause an implicit clone for each
329 operation. (It's still O(1) and practically instant.)
330
331 I'm considering adding back some of the immutable operations if I can come up with good names for
332 them, but for now, just `clone` it if you need it.
333
334 #### RRB Vector
335
336 `Vector` is now implemented as an
337 [RRB tree](https://infoscience.epfl.ch/record/213452/files/rrbvector.pdf) with
338 [smart head/tail chunking](http://gallium.inria.fr/~rainey/chunked_seq.pdf), obsoleting the previous
339 [Hickey trie](https://hypirion.com/musings/understanding-persistent-vector-pt-1) implementation.
340
341 RRB trees have generally similar performance characteristics to the Hickey trie, with the added
342 benefit of having O(log n) splitting and concatenation.
343
344 | Operation | RRB tree | Hickey trie | Vec | VecDeque |
345 | --------------- | -------- | ----------- | ------ | -------- |
346 | Push front | O(1)\* | O(log n) | O(n) | O(1)\* |
347 | Push back | O(1)\* | O(log n) | O(1)\* | O(1)\* |
348 | Pop front | O(1)\* | O(log n) | O(n) | O(1)\* |
349 | Pop back | O(1)\* | O(log n) | O(1) | O(1)\* |
350 | Lookup by index | O(log n) | O(log n) | O(1) | O(1) |
351 | Split | O(log n) | O(log n) | O(n) | O(n) |
352 | Join | O(log n) | O(n) | O(n) | O(n) |
353
354 (Please note that the timings above are for the `im` version of the Hickey trie, based on the
355 [Immutable.js](https://facebook.github.io/immutable-js/) implementation, which performs better than
356 the original Clojure version on splits and push/pop front, but worse on push/pop back).
357
358 The RRB tree is the most generally efficient list like data structure currently known, to my
359 knowledge, but obviously it does not and cannot perform as well as a simple `Vec` on certain
360 operations. It makes up for that by having no operations you need to worry about the performance
361 complexity of: nothing you can do to an RRB tree is going to be more expensive than just iterating
362 over it. For larger data sets, being able to concatenate (and, by extension, insert and remove at
363 arbitrary locations) several orders of magnitude faster than `Vec` could also be considered a
364 selling point.
365
366 #### No More `CatList` And `ConsList`
367
368 `CatList` has been superseded by `Vector`, and `ConsList` was generally not very useful except in
369 the more peculiar edge cases where memory consumption matters more than performance, and keeping it
370 in line with current API changes wasn't practical.
371
372 #### No More Funny Words
373
374 Though it breaks my heart, words like `cons`, `snoc`, `car`, `cdr` and `uncons` are no longer used
375 in the `im` API, to facilitiate closer alignment with `std::collections`. Even the `head`/`tail`
376 pair is gone, though `head` and `last` remain as aliases for `front` and `back`.
377
378 ## [10.2.0] - 2018-04-15
379
380 ### Added
381
382 - Map/set methods which accept references to keys will now also take any value that's borrowable
383 to the key's type, ie. it will take a reference to a type `Borrowable` where the key implements
384 `Borrow<Borrowable>`. This is particularly handy for types such as `String` because you can now
385 pass `&str` to key lookups instead of `&String`. So, instead of the incredibly cumbersome
386 `map.get(&"foo".to_string())` you can just do `map.get("foo")` when looking up a mapping for a
387 string literal.
388
389 ## [10.1.0] - 2018-04-12
390
391 ### Added
392
393 - `Vector`, `OrdMap` and `HashMap` now implement `Index` and `IndexMut`, allowing for syntax like
394 `map[key] = value`.
395 - Added `cons`, `snoc`, `uncons` and `unsnoc` aliases where they were missing.
396 - Everything now implements `Sum` and `Extend` where possible.
397
398 ### Changed
399
400 - Generalised `OrdMap`/`OrdSet`'s internal nodes so `OrdSet` now only needs to store pointers to
401 its values, not pairs of pointers to value and `Unit`. This has caused `OrdMap/Set`'s type
402 constraints to tighten somewhat - in particular, iteration over maps/sets whose keys don't
403 implement `Ord` is no longer possible, but as you would only have been able to create empty
404 instances of these, no sensible code should break because of this.
405 - `HashMap`/`HashSet` now also cannot be iterated over unless they implement `Hash + Eq`, with the
406 same note as above.
407 - Constraints on single operations that take closures on `HashMap` and `OrdMap` have been relaxed
408 from `Fn` to `FnOnce`. (Fixes #7.)
409
410 ### Fixed
411
412 - Hashes are now stored in `HashMap`s along with their associated values, removing the need to
413 recompute the hash when a value is reordered inside the tree.
414
415 ## [10.0.0] - 2018-03-25
416
417 ### Added
418
419 This is the first release to be considered reasonably stable. No changelog has been kept until now.