Make alloc optional (embedded rust)

[xoac]

Proposition:
I wonder if is it possible to make alloc optional. As far as I have checked the source code the main problem for make alloc optional is with implementation of Bytes and BytesMut that require alloc to work. To support partially bytes for embedded devices where alloc is not an option theses structs need re-implementation and this is complicated subject. Things that can be introduced to embedded word are Buf and BufMut traits and this works nearly out of the box.

Motivation:

• common interface for bytes on every level of rust

Here is example where alloc crate is a problem:

• example crate that used bytes with motivation above. This was done in 28 PR
• problem that MR generated: Latest version depends on alloc via BufMut rust-iot/rust-ieee802.15.4#33

---

Crate that could benefits from proposed changes:

• https://github.com/braun-embedded/rust-ieee802.15.4
• https://github.com/xoac/static-bytes

[taiki-e]

As said in #461 (comment), I don't think it's possible without breaking changes. See also crossbeam-rs/crossbeam#508 (comment).

[xoac]

So now the question is a little bit political. Are authors interested to make bytes crate embedded devices friendly? Since this issue was know before first major release maybe "not make alloc optional" was considered decision?

I think breaking changes are not a problem here, since you can just simply increment major release.

[taiki-e]

The main problem is that we recently released v1 and don't want to release v2 right away.

Since this issue was know before first major release maybe "not make alloc optional" was considered decision?

I don't think there was such a decision. I knew about such an issue, but I wasn't noticed that bytes had a similar issue until #461 reported.

To be clear: I'm basically in favor of doing this in the next major version.

[Kixunil]

There is a way to achieve embedded compatibility (and I hope MSRV 1.36) without breaking bytes API: jut move the traits only to a separate bytes-traits crate and reexport/implement them here. The embedded consumers can simply depend on that crate instead of bytes. I'm willing to make a PR for this.

[taiki-e]

There is a way to achieve embedded compatibility (and I hope MSRV 1.36) without breaking bytes API: jut move the traits only to a separate bytes-traits crate and reexport/implement them here. The embedded consumers can simply depend on that crate instead of bytes. I'm willing to make a PR for this.

Note that in this approach, it will break if the user runs cargo update after implementing the traits provided by the old version of bytes crate and the traits provided by bytes-traits crate.

[Kixunil]

@taiki-e isn't it the same problem as having two different versions of a crate?

[taiki-e]

@Kixunil "the old version of bytes crate" meant the 1.x.y version that does not contain the changes you suggested.

They are different traits in the 1.x.y version that does not contain the changes you suggested, but they are the same trait in the version that contains the changes.

[Kixunil]

I don't think it's a problem though. Either you have two version of the bytes crate but the same problem would happen without reexport or you have a single version and then it's non-issue.

I think you're describing this situation, please LMK if you mean something else
assuming bytes_old -> bytes_new is a minor or patch release, bytes_new moves the trait to a separate crate

• A depends on bytes_old

• B depends on bytes_old

• C depends on A and B, supplying A with types from B

• B changes to implement the traits from bytes-traits and stops depending on bytes

• C updates the version of B without updating bytes_old

C no longer compiles

In this case B is the one doing breaking change, not bytes.
B can also trivially improve it using the semver trick:

• B_non_breaking depends on B_breaking AND bytes_new
• B_breaking implements the change

[nils-van-zuijlen]

Wouldn't it be possible to have alloc as a default feature flag the way that serde does it?

As I see it, the only people that would be affected by that change would be the no_std group which have set the default-features = false, and not the wider audience that uses std via the default features.

[taiki-e]

@nils-van-zuijlen Please read previous comments (#479 (comment) and #479 (comment)).

[Kixunil]

@taiki-e I think I addressed that in my comment. Is there a specific scenario I'm missing?