FWIW, I'd like to bring an unconventional opinion on this matter: I personally have found that codebases that defaulted to prefixing extern crate names with the leading
:: diambiguator (Edition 2018 ofc.) reduced the cognitive burden / overhead and thus lead to more readable code.
For instance, when you have:
use some_crate::prelude::*; // typical Rust idiom
and then later see something like
oid::foo(), you can't know (without checking extra files), whether
oid is some module brought by the
prelude scope of
some_crate or if it is an external crate in and on its own. By defaulting to using the leading
:: disambiguator for the later case (with maybe an exception for the built-in crates, such as
std), you no longer have this disadvantage
- and for those who may occasionally write (procedural1) macros, it prevents forgetting to use robust paths
1 Non-procedural macros should always be using
$crate-qualified paths, reexporting (through
#[doc(hidden)] pub use ::crate_name)-, if needed, things such as
std, to feature macros that are 100% call-site context agnostic, and thus as robust as a function.