Transition out weak feature syntax in an edition

[ehuss]

Problem

The difference between package/feature and package?/feature syntax is unfortunate as it can be a little confusing and inelegant. Ideally we would have kept the original syntax, but the ? was added to retain backwards compatibility.

Proposed Solution

It might be worth considering dropping the ? syntax in the next edition. package/feature would behave the same as the ? variant. With the use of toml_edit, it may be possible to enhance cargo fix in order to automatically update Cargo.toml to retain backwards compatibility. If the package is optional, then it would rewrite the [features] table to convert "package/feature" to "dep:package", "package/feature" (and also possibly define a feature named "package" if it doesn't already exist and dep:package isn't already used).

Notes

No response

[epage]

There was a recent zulip thread on this.

One idea brought up is to start by deprecating dep/feature syntax, likely gated by an MSRV check. One of the challenges with this is in collecting user feedback. A deprecation is a two-way door that we can leverage to raise awareness of the change to help decide if this is a direction we'd want to commit to. If we get little actionable negative feedback or if the feedback is generally positive, those could be good signals for deciding to change the dep/feature syntax meaning on a new edition.

[epage]

I believe the issue hints at it but its easy to overlook. A subtle difference between "dep_name/feature_name" and "dep:dep_name", "dep_name?/feature_name" is that dep: is required to suppress the creation of the implicit feature.

This came up in #14010