@epage Do you want to take on implementation of this, or know someone who will? Or, if not, do you want to write mentoring instructions? I can probably do that if you don't.

@Muscraft is taking this on atm as his test case for #12235. We should pick a time to re-evaluate and, if that isn't ready in time, we pivot and hard code all of this where it is needed.

@Muscraft and I have been talking about how to implement this.

Instead of erroring in the 2024 Edition that an implicit feature was created, we are looking at treating it as an "unused optional dependency" warning. However, to truly be unused, no implicit feature should be created.

So how do we avoid that implicit feature?

Option 1: We strip unused optional dependencies before generating a Summary / before publish

This will "just work". All past and future versions of Cargo will not be able to access an implicit feature.

This would be an impediment to running other lints on unused optional dependencies because we'd be throwing out the information we'd use for linting.

This means that unused optional dependencies would not affect dependency resolution and not be included in Cargo.lock, like workspace.dependencies and unlike unused transitive dependencies from weak features (#10801).

Option 2: We include the edition in the summary

We then use edition to decide whether optional dependencies should have implicit features created.

Maybe other future work could benefit from this?

This would be quite a bit of work, requiring crates.io changes and communicating out changes required for third-party registries to support Edition 2024. But we only have 2 weeks left and coordinating across teams within that time span might be difficult.

Without a index format bump or required MSRV, old cargo will ignore Edition, allow these, and create implicit featurese

Option 3: We punt and have this warning be an error

Nuff said

Option 4: When generating the Summary / published Cargo.toml, we create foo = ["dep:foo"] features for pre-2024 Edition

The problem with this is it would require a server backfill to function properly which in a way would be a breaking change for third-party registries

Option 1: We strip unused optional dependencies before generating a Summary / before publish

So this RFC implemetation can also fixed or mitgiate #10801 ?

No, that is unrelated to what was being proposed to be stripped.

The cargo team has decided to drop this from the 2024 edition. There are some implementation issues, and we feel that there is just too much risk trying to resolve it at such a late date. We will update here when we have decided what to do in the future.

#14630 removes the removal of implicit features from Edition 2024.

#14016 has a note explaining what led to this problem and some potential solutions.