When you say that sounds like a feature, do you mean that library authors would be expected to issue a major version bump when introducing new unstable feature dependencies? If so, that would be extremely strong disincentive to do so, thereby defeating the main goal of the effort.
Well in line with my “ideal scenario” example in my last post, I can complicate my proposal to get the best of both worlds.
- Cargo.toml tracks the Rust language version include unstable features
- Cargo passes those unstable features to rustc, avoiding the need for duplicate attributes.
- Cargo only resolves dependencies such that downstream’s feature whitelist is respected (rules may very for root/executable vs interior/library nodes, as we see fit)
Now it’s never a breaking change and we still have fully stable Rust: root node has empty unstable feature whitelist, which is the default. So fully stable is still explicit and opt-out, yet adding more features (like any other requirement, e.g. dependencies) is never a breaking change. Woo!