The announcement post of the 2021 edition includes a section about making
resolver = "2" default as part of this edition. I want to use this post to raise my concerns about changing the default resolver as part of the next edition, I do not want to discuss the general need of this feature or a specific design nor want I question that this feature unblocks certain use cases.
First of all the blog post states the following:
Editions do not split the ecosystem
The most important rule for editions is that crates in one edition can interoperate seamlessly with crates compiled in other editions. This ensures that the decision to migrate to a newer edition is a "private one" that the crate can make without affecting others.
The requirement for crate interoperability implies some limits on the kinds of changes that we can make in an edition. In general, changes that occur in an edition tend to be "skin deep". All Rust code, regardless of edition, is ultimately compiled to the same internal representation within the compiler.
I cannot see how this statement is true for the
resolver = "2", as using the new resolver is nothing that is contained to a specific crate. It applies to the whole dependency tree and therefore forces the behaviour down to all dependencies. In my opinion this violates that the decision of migrating to a newer edition as a "private one" that a crate can make without affection others.
Crates may have been written before the new resolver were even a thing and could relay on the behaviour of the old resolver. Especially for popular crates this will likely create a large pressure to support the new behaviour even if this would imply a breaking change or results in decreased usability due to users have to specify matching feature flags for different crates now. Essentially this places the cost of doing a breaking change to the resolver algorithm onto the ecosystem instead.
See this cargo issue for a specific issue encountered due to this.
To finish this with something that is actually actionable: I can see that
resolver = "2" is a feature that is needed to unblock specific use cases. I don't think it should be the default in the next edition, for the reasons outlined above. On top of that I would like to see improvements about the documentation/messaging around this feature. Specifically I believe that if cargo encounters an error building a specific dependency with the new resolver it should emit a bold warning that this is likely caused by opting into the new resolver behaviour and is not a bug in the corresponding crate. It would be great to also get a suggestion from cargo how to fix the specific problem by either suggesting adding a specific dependency with corresponding feature flags based on a diff between the dependency tree build by the different resolver methods or by just suggesting to try the old resolver instead.