Why is tokio_unstable not simply a Cargo feature?

[BatmanAoD]

The cfg rustflag is trickier to set than a Cargo feature, and it's also easier to accidentally suppress it (e.g. the corresponding .cargo/config.toml field is ignored if one of the env vars is set, and the target-specific env var suppresses the RUSTFLAGS env var). Additionally, as far as I can tell, it's not possible to control tokio_unstable with cargo hack (issue).

Given that, why control unstable behavior this way, rather than with a feature flag? I can think of a few potential benefits:

• the higher friction is desirable to discourage use of tokio_unstable
• accidentally enabling it e.g. with --all-features would be a worse user experience for users who don't want it, compared to users who want it accidentally disabling it as described above

Are there any other reasons?

[ADD-SP]

The tokio_unstable has already caused some issues. see #5875 and #7546. And also causes some troubles when using the --all-features.

I think it is fine to start the discussion on improving it. For example, introducing several unstable-<feature-name> cargo features and remove the tokio_unstable.

[Darksonn]

It's to ensure that downstream crates do not enable it without the end-users knowledge. With a cargo feature, random third party librarys can just enable it without you even having to know about it. Whereas with --cfg tokio_unstable, the end-user of the library has to explicitly decide to enable it.

[ADD-SP]

This is a good point.

[BatmanAoD]

Oh, that makes sense. Thanks!