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.
I’m quite pleased with how this has turned out.
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.
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.
Somewhere along the path I didn’t mark some functions as `#[inline]`
which they should probably be.
Small but visible benchmark improvements, but within ε so low
confidence.
