The framing of the problem for a lot of the original discussion was around “path confusion,” the idea that absolute paths (i.e.
pub(in), or with variant 3
::) overlap with in-scope paths in the root module, leading beginners to build incorrect mental models that aren’t broken until they go to add a new source file and get confused.
The last line of your example kind of undermines its ability to solve this problem- in the root module, top-level items and dependencies are still in-scope for undeprecated use, at least without further rules around what’s deprecated.
Another issue is that there was some level of support for
use paths staying absolute by default, both for backwards compatibility and avoiding churn (
use regex, etc don’t have to change at all with the RFC/variant 2), and because a lot of
uses cross the module tree, at least in some codebases.
Variant 2 helps here because it makes it immediately clear that
use paths are absolute- you can’t
use something out of a top-level item without prefixing it with
crate, because your crate is just one among many.
In that light, I think variant 2 arguably has less breakage already. Variants 1 and 3, as well as your suggestion, all force every path to change. Variant 2 only forces internal paths to change, allowing external paths (which IIRC actually turned out to be the majority based on some numbers gathered in the RFC thread) to remain undeprecated.
(And to avoid retreading some ground from the RFC thread: we really can’t fix this problem without forcing some set of paths to change, based on the “path confusion” framing.)