Given the stability-despite-instability of hashbrown (that the API
surface we’re depending on hasn’t changed since 0.1.1), and the
deliberate altered SemVer guarantees for it, it was very tempting
to leave the hashbrown range open, `version = ">=0.1.1"` or at least
`version = ">=0.1.1, <1"`, but for some reason or other I ended up
deciding not to. I’m still of two minds about it, really.
Refactor to avoid a spurious compatibility warning
Explained in the SAFETY comment. I’m not happy about *doing* this, but
it will make *using* this crate easier, since future-compatibility lints
make noise on bin crate builds, so this was polluting other people’s
code and making life harder for users.
I have traded one evil (a spurious warning) for another (unsafe code).
Turns out its commenting technique was completely broken—the attributes
have to be attached to an item *inside* the macro, not outside. And
judging by https://docs.rs/anymap/0.11.0/anymap/any/trait.CloneAny.html,
it was broken from the start, and I never noticed. Sigh. Now, you get a
warning that it’s not going to work like you want. Good stuff.
Well, that macro wasn’t a great idea anyway. Doing without it ends up a
little longer, and risks inconsistent editing, but is decidedly easier
to read.
All but one of these are definitely trivial, obvious, and in the context
of the project and ecosystem not creative works (⅌ copyright doctrine
definition); or else no longer present. The one arguable exception is 2e37f0d1aebbd0c56acd0de7b46d14cd71d3e134, adding AnyMap::contains, since
I hadn’t added a contains method; but its *definition* is trivial with
only one possible implementation, and subsequent to that time I did go
through and check for parity with HashMap methods, to say nothing of the
code having changed shape quite a bit since then too. Therefore I’m
content to consider it immaterial for relicensing.
There’s nothing wrong with this patch, but I had never pulled this
commit to my local repository and had completely forgotten about it, and
today removed the unsafe code in a *different* direction that I like
better (`bytes.try_into().map(|bytes| u64::from_ne_bytes(bytes))`), so
reverting it so I can cleanly rebase is just easier for me!
It was implemented on RawMap, and I’m not sure quite why it wasn’t
implemented on Map. I can’t think of any reason *not* to, though, so we
might as well.
Closes #30. Thanks to Maxwell Koo <mjkoo90@gmail.com> for the fix.
A better pattern is to put benchmarks in the `benches` directory;
that way, `cargo test` won’t pick them up by default,
and so it won’t fail on the stable and beta channels.
This *does* mean that they no longer function as tests, which was
deliberate, but rustc is just too slow with the assertions in there as
well. If I care, I can make variants of it that actually test. For now,
I’m sufficiently happy with it.
Substantial refactoring, exposing a raw interface.
This is not necessarily the final form, but I think it’s pretty good.
The only alteration to the public interface is the removal of the
iteration methods from `AnyMap`; they are now attached to `RawAnyMap`.
The diff appears considerably more scary than it is in actual fact due
to some comparatively unnecessary changes like the field name (from
`data` to `raw`). Really, it’s minimal.
This entails the addition of various methods and iterator types where
appropriate, based on what’s on `HashMap`, though I doubt that people
will actually be able to make all that much use of the iterators. They’d
be of more use with a basis of a trait other than `Any`, such as might
be conveniently achieved by combining this with my MOPA crate.
(Getting a little close to HKT there, innit?)
You know, I wonder sometimes if anyone ever reads these messages after
they are written, myself included. If you have read this, please drop me
a note; I’m curious.
I’ve also gone over all the stability attributes, marking things as
appropriate.
This includes following the standard new semantics for `insert` and
`remove`, where they return any value that was previously present, and
renaming `find` and `find_mut` to `get` and `get_mut`. For the moment,
I’ve even provided a deprecation path! Will wonders ever cease?