Issues with hashbrown 0.4 -> 0.5 upgrade

[tarcieri]

hashbrown::HashMap is part of the public API of this crate in several places, e.g.:

https://docs.rs/handlebars/2.0.1/handlebars/struct.Handlebars.html#method.get_templates

Between Handlebars 2.0.0 and 2.0.1, hashbrown was updated from 0.4 to 0.5. This broke installation of my crate (cargo install abscissa), since it was using hashbrown v0.4.

Some options I can think of:

• Re-export either hashbrown (e.g. pub use hashbrown in the crate root) or hashbrown::HashMap so I don't have to depend on the hashbrown crate
• Wrap hashbrown::HashMap in a newtype
• Switch to std::collections::HashMap as std is switching to hashbrown anyway

[sunng87]

I see. That was a common issue in rust ecosystem. To be practical I will be reexport those types used in public APIs, that was your 1 solution.

And I will be releasing the change in a patch version, do you think it works for you?

[tarcieri]

@sunng87 I think the best option is probably to switch back to std::collections::HashMap since std will be incorporating it anyway.

That said, whatever works: I'd be happy for a 2.0.2 that re-exports the hashbrown type as a solution too

[sunng87]

That was annoying because either reexporting or switching to std HashMap is actually a breaking change, that requires a major version bump if we are strict on semver. I have to prevent it from breaking more applications if they depend on that API.

I will benchmark performance between current hashbrown and the one in std to decide if I will switch in future.