Transition out implicit features for optional dependencies

[epage]

Problem

Today cargo will implicitly create a feature for optional dependencies unless the dependency is referenced in a feature as dep:<dep_name>.

Downsides

• People overlook using dep: and unintentionally create features
  • Exposing implementation details in their public API
  • Confusing users on which features to activate (Friction log: optional deps in features list confusing #9459)
• Remove the need for people to special case this (e.g. Breaking change: cargo metadata no longer distinguishes between "magical" features from optional deps and normal features #10543)
• Avoid mistakes with explicitly creating the feature (Confusing error when adding optional dependency to [features] #10125)

Proposed Solution

We should stop implicitly creating features in a new Edition

Optional dependencies without a dep: reference can be either

• A hard error
• Allowed assuming people will then want to use it via the future #[cfg(accessible)]
  • The downside is users might assume a feature would exist (at first) and things not work as expected
  • We could start with an error and move away from it
• Create private features (private/hidden features #10882, see also Allow optional dev-dependencies #1596)

cargo add foo --optional can implicitly create a feature with the dependency's name, if a dep:foo doesn't already exist (#11010).

Notes

No response

[epage]

See also #9088

[epage]

The main hurdle for transitioning is that #12130 was just barely merged though there is the workaround of "dep:foo", "foo?/feat" which would be the standard way of doing it with #10556.

[ehuss]

@epage Do you want to keep this issue open?

[epage]

If this were about a specific use case then I might want to keep it open but since its effectively "lets make an RFC", lets close it out.