Feature Request: Default implementations for heap types which support the unstable allocator API

[dylanplecki]

Rust has introduced new generic arguments to collection and other heap types such as Vec and Box called the "allocator_api". The idea behind this new API is to allow for custom allocators to manage the memory of these types on the heap.

This feature is currently marked as unstable on Rust nightly, but is becoming more widely used, especially in no_std environments where allocations should be marked as more explicit and controlled.

Currently, the bytes crate has default implementations for Buf and BufMut on some heap types (such as Box and VecDeque), but does not support custom allocators for these default implementations. For users, it is then impossible to automatically implement these traits for the heap types that support custom allocators, since both the trait and the heap type are defined outside of the current crate. This would require a wrapper struct to implement within another crate, which is inconvenient and muddies the code with extra types.

The solution to this is a quite simple feature addition, where the bytes crate adds a new feature called allocator_api that conditionally enables the Rust nightly/unstable allocator_api feature and compiles new default implementations for the heap types already present.

This new allocator_api feature will be disabled by default for the bytes crate. Users who wish to opt-in to this feature can enable it manually, until the allocator_api feature is stable.

I've written up a PR to address this feature request and will attach it to this issue.

[seanmonstar]

Perhaps some of the other maintainers have different opinions, but my feeling is not to have nightly APIs in the bytes crate. Nightly features tend to have churn, and once it stabilizes, the crate versions that supported it as a nightly feature stop working.

It's fine to experiment, but I wouldn't do so and publish such a fundamental crate as bytes. Once the libstd developers stabilize it, we can adopt it.

[dylanplecki]

Absolutely agreed, unstable feature support in public crates does tend to have a code smell to it.

That being said, the allocator_api feature has had some good support for it in public crates. Most notably off the top of my head, the hashbrown crate supports it via a third-party crate that re-exports the unstable allocator interfaces into a stable crate called allocator-api2 (hashbrowns cargo link).

If we want to support the allocator API (i.e. for no_std projects), we can alternatively go the route of using that third-party allocator-api2 crate as hashbrown did (which already supports the ability to optionally drop it to the nightly version).

Link to a similar discussion on hashbrown: rust-lang/hashbrown#417

[Darksonn]

I'm sorry, but we don't have enough maintainer bandwidth to support something unstable that may require changes in the future.

[dylanplecki]

Understandable, and thank you for the continued maintenance.

Since there is a reasonable alternative here to wrap the allocator types in local structs and then re-implement Buf and BufMut, I'll close this issue & related PR, then reopen later pending stabilization of the allocator_api feature.