WIP: Make alloc optional

[xoac]

This contains an easy way of making alloc optional. #479

[paolobarbolini]

I would assume that more than 3 years after v1 release we can allow a major update that would allow more people to finally use this lib.

The issue I see with it is that bytes is part of the public API of tokio, so that's the situation unfortunately.

[maximeborges]

(Sorry, I moved my comment to another issue that seemed to have more people following since I saw that there was no reviewer on this PR)

The issue I see with it is that bytes is part of the public API of tokio, so that's the situation unfortunately.

Since the current major version is 1, how having a breaking change to a new major version would be a problem?

[paolobarbolini]

Since the current major version is 1, how having a breaking change to a new major version would be a problem?

The issue is that it creates a lot of friction if bytes v2 gets released but tokio based crates stay at v1

[maximeborges]

So what would be the recommended way for libs/app code base who have to support async/tokio down to no_std/no_alloc? Just use another lib?
It sounds like changing a single line in Cargo.toml (i.e. adding features = ["alloc"] when already using default-features = false, which might not even break if they are not using alloc functionalities in the first place) in the few projects (that aren't using tokio because they are no_std) would be far less work than making whole libs/apps switch to another similar lib to properly support those functionalities.
Note that manipulating bytes safely makes particularly more sense on constrained devices (those no_std/no_alloc ones), and using a single, reliable library everywhere would be very nice for the ecosystem.
I would even consider putting that into a minor update, since this simply fixes a feature definition mistake when releasing v1, and shouldn't deeply impact a lot of projects.

[Darksonn]

I'll close this in favor of #606.