Feature Request: Default implementations for heap types which support the unstable allocator API about bytes HOT 4 CLOSED

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.

from bytes.

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

from bytes.

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

from bytes.

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.

from bytes.