Suggestion: don't enable any feature flags by default in v2

[geeklint]

bytes v1 currently has two feature flags: std and serde, the former of which is enabled by default. bytes v2 is projected have these flags plus an additional flag for alloc. I propose that none of these are enabled by default, in effect demoting the std feature.

Pros:

• Appears to be consistent with tokio.
• Reduces the chance of a library accidentally depending on a feature flag it doesn't need.
• Less toml syntax for projects excluding the default features.
• If the condition listed below is met, would allow a future change like the one that triggered the current major version update to be done without a major version update.

Cons:

• More toml syntax for projects including the default features, which may be a larger demographic.
• If the condition listed below is not met, doesn't help with future semver compatibility.

This can be carried out within the proposed "semver hack" because bytes v1 can forward its feature flags to bytes v2. When bytes v1 is used with default-features enabled, the features it enables will be enabled in bytes v2, regardless of the state of default-features on bytes v2.

The future semver compatibility benefit is conditional on what the project considers a breaking change. The proposal for an optional alloc feature could not be implemented in bytes v1 because it would be a regression for dependents who specify default-features = false. For bytes v1, there is a good reason a dependent would do that - they want to support no_std use cases. Under this proposal, it would still be true that making existing functionality optional would be a breaking change for dependents who specify default-features = false. The difference is that there is no longer a reason for a dependent to do that. The future semver compatibility benefit is conditional on if the project considers "specifying default-features = false in the absence of default features" a supported use case that should not be broken by semver compatible upgrades.

[Kixunil]

FYI there is a trick to have future compatibility even if the condition is not met. It requires preemptively adding a new feature everything-else-v1 and make it so that the entire crate is empty if the feature is not enabled. (I'd recommend keeping it default though) This forces people who use default-features = false to commit to specific feature version by specifying features = ["everything-else-v1"]. Then later, when a new feature (let's call it foo) is added that would remove items from the API, a new everything-else-v2 feature is added as well, replacing everything-else-v1 in the empty crate condition and the everything-else-v1 feature is made to depend on both foo and everything-else-v2, so everything works fine for old consumers. The consumers can then bump the version if they don't need the functionality at their own discretion.

I'm not saying it's great and I doubt it'll be needed in this crate but may be worth considering.