2017-01-21 02:58:07 +11:00
|
|
|
|
# 1.0.0 (unreleased)
|
|
|
|
|
|
|
2022-01-25 19:39:20 +11:00
|
|
|
|
Planned once the dust of 1.0.0-beta.1 settles, since 1.0.0-beta.1 ended up
|
|
|
|
|
|
being bigger than I’d earlier intended.
|
|
|
|
|
|
|
Rename UncheckedAnyExt, fix Extend, tweak things
The *name* UncheckedAnyExt was ending up visible in docs, but it had
become an increasingly unpleasant name. “Downcast” is suitable, though,
being private, it’s not still not perfect. But there’s no point in
making it public, as people generally can’t implement it because of
coherence rules (I tried).
Plus documentation and style changes.
As for Extend, eh, that should ideally be in a different commit, but
it’s here now, and I’m the only one working on this code base in
general, so I permit myself to be slightly lazy from time to time.
Trouble was Downcast should never have had an Any supertrait, as it was
grossly misleading, leading to type_id giving `dyn Any`’s TypeId rather
than the underlying type’s.
2022-02-03 00:40:47 +11:00
|
|
|
|
# 1.0.0-beta.2 (unreleased)
|
|
|
|
|
|
|
|
|
|
|
|
- Fixed the broken `Extend` implementation added in 1.0.0-beta.1.
|
|
|
|
|
|
|
2022-01-25 19:39:20 +11:00
|
|
|
|
# 1.0.0-beta.1 (2022-01-25)
|
|
|
|
|
|
|
2022-01-25 19:47:19 +11:00
|
|
|
|
- Removed `anymap::any::Any` in favour of just plain `core::any::Any`, since its
|
2022-01-25 15:59:28 +11:00
|
|
|
|
`Send`/`Sync` story is now long stable.
|
|
|
|
|
|
|
|
|
|
|
|
- This loses `Any + Sync`. `CloneAny + Sync` is also removed for consistency.
|
|
|
|
|
|
(So `Any + Sync` is gone, but `Any`, `Any + Send` and `Any + Send + Sync`
|
|
|
|
|
|
remain, plus the same set for `CloneAny`.)
|
|
|
|
|
|
|
|
|
|
|
|
- `anymap::any::CloneAny` moved to `anymap::CloneAny`.
|
|
|
|
|
|
With nothing public left in `anymap::any`, it is removed.
|
2022-01-25 14:43:04 +11:00
|
|
|
|
|
2022-01-25 12:40:30 +11:00
|
|
|
|
- Relicensed from MIT/Apache-2.0 to BlueOak-1.0.0/MIT/Apache-2.0.
|
|
|
|
|
|
|
2022-01-25 21:24:48 +11:00
|
|
|
|
- Increased the minimum supported version of Rust from 1.7.0 to 1.36.0.
|
|
|
|
|
|
|
|
|
|
|
|
- no_std is now possible in the usual way (default Cargo feature 'std'),
|
|
|
|
|
|
depending on alloc and hashbrown.
|
2022-01-25 14:12:16 +11:00
|
|
|
|
|
2022-01-25 19:31:36 +11:00
|
|
|
|
- Removed the `bench` Cargo feature which was mostly to work around historical
|
|
|
|
|
|
Cargo limitations, but was solved by moving benchmarks from `src/lib.rs` to
|
|
|
|
|
|
`benches/bench.rs` even before those limitations were lifted. The benchmarks
|
|
|
|
|
|
still won’t run on anything but nightly, but that don’t signify.
|
2017-01-21 03:01:56 +11:00
|
|
|
|
|
2022-01-25 19:31:36 +11:00
|
|
|
|
- Implemented `Default` on `Map` (not just on `RawMap`).
|
2017-10-02 14:32:51 +11:00
|
|
|
|
|
2022-01-25 23:52:13 +11:00
|
|
|
|
- Added `Entry::{or_default, and_modify}` (std::collections::hash_map parity).
|
|
|
|
|
|
|
Replace the raw module with just hash_map
When I implemented Extend<Box<A>> for Map<A>, I thought:
can I implement Extend<(TypeId, Box<A>)> for RawMap<A>,
as HashMap<K, V> implements Extend<(K, V)>?
No, I responded, for insert is unsafe,
and a trait implementation cannot be marked unsafe.
Then said I, hang on, why is insert unsafe?
For by analogy with pointers, creating a dangling pointer is safe,
it’s only dereferencing it that’s unsafe;
so too here could insertion be safe and retrieval unsafe.
Then I realised: RawMap is actually completely safe, of itself;
the reason the unsafety is needed is AsMut<RawMap<A>> for Map<A>:
that retrieval is defined as safe, so insertion need be done delicately.
And so I consulted with myself and wondered:
Would it not be better to drop AsMut,
exposing rather an `unsafe fn as_raw_mut`?
For `AsRef<RawMap<A>>` and `Into<RawMap<A>>` may yet be safe,
yet this would take RawMap towards parity with HashMap.
And yet further went I,
descending into depths unplumbed these five years,
saying unto myself:
Wherefore RawMap<A> at all?
Why not rather HashMap<TypeId, Box<A>, BuildHasherDefault<TypeIdHasher>>,
accessed freely and safely by reference or Into,
and unsafely as discussed in the previous stanza
(if I may call it such)?
Striving to understand the matter,
it was a wearisome effort,
and I could not.
I consulted with 143ee062680311ca9c2ed5b7089bb0d741bc17c0,
yet with the passage of nigh seven years it was not able to tell me
just why I had thought this might be a good idea.
For lo, those were the benighted ages before Rust 1.0.0,
though the glimmer of that bright dawn danced on the horizon
like the latter part of an arctic winter.
And so, casting away the trammels of history
I forged a new path.
For lo! had I not even then declared it
“not necessarily the final form”?
Casting RawMap away from me and clasping HashMap to my bosom,
I found the required diff in lib.rs
such a delicate thing,
so slight.
It was pleasing in my eyes, and so forthwith I decided:
hew down the unwanted abstraction,
and bind it with a band of iron and bronze,
that it may grow no more.
So need I not add more features to it,
mere shadows of the true HashMap underneath.
Oh fortunate day!
Three-hundred-odd lines removed,
(though more detailed comments offset this,
so that the end result is more like 223,)
and simplicity restored.
Well, except for this fly in the ointment:
std versus hashbrown.
Woe unto the person who calls a raw map std::collections::HashMap,
for when another comes and enables hashbrown,
the first shall crumble into nothingness and errors most distressing.
The mitigation of this is `pub type RawMap<A>`,
augmented by the very truth that,
few using this feature,
few may stumble!
Yet there are difference betwixt the twain,
seen in my cfg branching on VacantEntry and OccupiedEntry,
and this *is* a very mild violation of the principle of strictly additive features.
There ’tis: the tale of an abstraction unravelled.
Unravelled? Feels more like “not ravelled” rather than undoing ravelling.
Deravelled? Disravelled?
I shall but brand the abstraction a dead princess, as it were,
and this my pavane pour un infante défunte.
And if you, dear reader—
if reader there be of this screed that has grown rather longer than originally anticipated but also probably more entertaining if you don’t mind this sort of thing or share a similar sense of humour to me—
have aught to opine on the matter,
You know my email address.
2022-01-25 23:38:47 +11:00
|
|
|
|
- Removed the `anymap::raw` wrapper layer around `std::collections::hash_map`,
|
|
|
|
|
|
in favour of exposing the raw `HashMap` directly. I think there was a reason
|
|
|
|
|
|
I did it that seven years ago, but I think that reason may have dissolved by
|
|
|
|
|
|
now, and I can’t think of it and I don’t like the particular safe
|
|
|
|
|
|
`as_mut`/unsafe insert approach that I used. Because of the hashbrown stuff,
|
|
|
|
|
|
I have retained `anymap::RawMap` is an alias, and `anymap::raw_hash_map` too.
|
|
|
|
|
|
The end result of this is that raw access can finally access things that have
|
|
|
|
|
|
stabilised since Rust 1.7.0, and we’ll no longer need to play catch-up.
|
2022-01-25 19:21:15 +11:00
|
|
|
|
|
2022-01-25 13:48:23 +11:00
|
|
|
|
- Worked around the spurious `where_clauses_object_safety` future-compatibility lint that has been raised since mid-2018.
|
|
|
|
|
|
If you put `#![allow(where_clauses_object_safety)]` on your binary crates for this reason, you can remove it.
|
|
|
|
|
|
|
2017-01-21 02:58:07 +11:00
|
|
|
|
# 0.12.1 (2017-01-20)
|
|
|
|
|
|
|
|
|
|
|
|
- Remove superfluous Clone bound on Entry methods (#26)
|
|
|
|
|
|
- Consistent application of `#[inline]` where it should be
|
|
|
|
|
|
- Fix bad performance (see 724f94758def9f71ad27ff49e47e908a431c2728 for details)
|
|
|
|
|
|
|
|
|
|
|
|
# 0.12.0 (2016-03-05)
|
|
|
|
|
|
|
|
|
|
|
|
- Ungate `drain` iterator (stable from Rust 1.6.0)
|
|
|
|
|
|
- Ungate efficient hashing (stable from Rust 1.7.0)
|
|
|
|
|
|
- Remove `unstable` Cargo feature (in favour of a `bench` feature for benchmarking)
|
|
|
|
|
|
|
|
|
|
|
|
# 0.11.2 (2016-01-22)
|
|
|
|
|
|
|
|
|
|
|
|
- Rust warning updates only
|
|
|
|
|
|
|
|
|
|
|
|
# 0.11.1 (2015-06-24)
|
|
|
|
|
|
|
|
|
|
|
|
- Unstable Rust compatibility updates
|
|
|
|
|
|
|
|
|
|
|
|
# 0.11.0 (2015-06-10)
|
|
|
|
|
|
|
|
|
|
|
|
- Support concurrent maps (`Send + Sync` bound)
|
|
|
|
|
|
- Rename `nightly` feature to `unstable`
|
|
|
|
|
|
- Implement `Debug` for `Map` and `RawMap`
|
|
|
|
|
|
- Replace `clone` Cargo feature with arcane DST magicks
|
|
|
|
|
|
|
|
|
|
|
|
# Older releases (from the initial code on 2014-06-12 to 0.10.3 on 2015-04-18)
|
|
|
|
|
|
|
|
|
|
|
|
I’m not giving a changelog for these artefacts of ancient history.
|
|
|
|
|
|
If you really care you can look through the Git history easily enough.
|
|
|
|
|
|
Most of the releases were just compensating for changes to the language
|
|
|
|
|
|
(that being before Rust 1.0; yes, this crate has been around for a while).
|
|
|
|
|
|
|
|
|
|
|
|
I do think that [`src/lib.rs` in the first commit] is a work of art,
|
|
|
|
|
|
a thing of great beauty worth looking at; its simplicity is delightful,
|
|
|
|
|
|
and it doesn’t even need to contain any unsafe code.
|
|
|
|
|
|
|
|
|
|
|
|
[`src/lib.rs` in the first commit]: https://github.com/chris-morgan/anymap/tree/a294948f57dee47bb284d6a3ae1b8f61a902a03c/src/lib.rs
|