Issue deprecation warning on Code if identity feature is enabled

[thomaseizinger]

This is a PoC for the discussion in #201 (comment).

[Stebalien]

Nice!

Will this get triggered in a dependency? I.e.:

• I start with A -> B -> multihash.
• Then I add A -> C -> multihash ("identity").

[thomaseizinger]

Nice!

Will this get triggered in a dependency? I.e.:

* I start with `A -> B -> multihash`.

* Then I add `A -> C -> multihash ("identity")`.

As soon as the feature is enabled in the dependency graph, your usage of Code will be flagged as deprecated. Starting from there, your code (pun intended) can trigger the foot-gun. What might be annoying is that users cannot turn off the deprecation warning if a newly added dependency turns in on unconditionally. For those cases, they can say #[allow(deprecated] if they are sure that they never pass 0 into the try_from function.

[Stebalien]

I see. That definitely helps, although I'm still concerned about the case where the user doesn't actually use Code. They just happen to import two crates that do, and one of these crates enables this feature (breaking the other crate).

[thomaseizinger]

I see. That definitely helps, although I'm still concerned about the case where the user doesn't actually use Code. They just happen to import two crates that do, and one of these crates enables this feature (breaking the other crate).

Warnings that entirely appear within dependencies are silenced by cargo as far as I know. If you compile a project with max verbosity, I think you can still see them.

There is obviously still the problem where the foot-gun sits within a dependency and is triggered there.

One could argue that shipping a backwards-compatible deprecation warning first will make it easier for users to upgrade and thus have them see it earlier.

[Stebalien]

Yeah, I agree. Let's do both.

[thomaseizinger]

Before we ship this, let me remove our dependency on it in rust-libp2p and cut a patch release, otherwise we might trigger exactly what we just said: A deprecation warning that users can't fix themselves.

[thomaseizinger]

Closed in favor of #289.