RawTable allocator can't be used by stable code

[cuviper]

I see that #133 tried to make RawTable's allocator parameter safe for stable code:

• RawTable has a new type parameter, A: Alloc + Clone
• When the nightly flag is passed, Alloc will be the trait in alloc::Alloc.
• On stable, a minimal shim implementation is provided, along with an implementation for the global allocator.

However, I don't think this is sufficient as-is. There is an unfortunate side effect that crate features can be enabled indirectly, forcing the unstable feature on crates that aren't prepared for it. For instance:

• Suppose I update indexmap to hashbrown 0.10 with just the "raw" feature, not "nightly". I'll use the stable shim version of hashbrown::raw::Global, and it seems fine.
• Something else in a user's dependency graph enables hashbrown "nightly". It should be fine if the user is opting into the nightly compiler for their project.
• indexmap now fails to compile for lack of #![feature(allocator_api)], since Global became the unstable type from std.

I think this might have been avoided if RawTable had a default A = Global, so indexmap wouldn't have to name it at all. It also seems problematic that with_capacity needs an allocator parameter, although Default::default() seems to work ok. I would have expected it to remain without that parameter though, perhaps with_capacity_in for that instead, like new/new_in.

Even with default A = Global, I think it's a problem that Global may or may not require #![feature(allocator_api)]. A stable user might explicitly choose to specify the "stable" Global, and still have the rug pulled out when "nightly" is enabled elsewhere. This is also true of HashMap and HashSet which do have A = Global now.

[cuviper]

I think the safest bet would be to add A = Global, and then have the entire stable-shim implementation exist only as pub-in-private, not actually reachable outside the crate. This way stable users can only use an implicit Global, and nightly users must use the actual unstable paths from the standard library.

[Amanieu]

Several people have interest in using hashbrown with bumpalo, which was the original motivation for adding allocator support to hashbrown.

Perhaps this is better exposed by adding a "bumpalo" optional feature that specifically exports a BumpHashMap on both stable and nightly?

[Amanieu]

I've yanked 0.10.0 until this gets resolved.

[cuviper]

I started working on my suggestion for defaults and hidden (pub-in-private) shims. I think that may be orthogonal to adding bumpalo-specific types.