The Great Module Adventure Continues

language design
33

How is variant 3 (::std/::crate) different from variant 2, other than requiring the leading ::? Leading :: already has a meaning in both use/pub(in) and expressions, so wouldn’t it have the same need for fallback? (Although perhaps less frequently because use tends to avoid leading ::…)

Either way, looking at the old thread, one thing we missed here is that variant 2 don’t actually need fallback anyway if we gate the change on an epoch: https://github.com/rust-lang/rfcs/pull/2126#issuecomment-328998289

Instead, in this epoch, we:

  • Introduce crate::
  • Deprecate unused Cargo.toml dependencies
  • Deprecate non-root use of extern crate
  • Introduce Cargo.toml crate aliases
  • Deprecate absolute paths that don’t begin with one of:
    • A potentially-aliased dependency name (which given the other deprecations, must now be a non-conflicting top-level extern crate item, if it is to avoid warnings)
    • crate (which is new, and so can avoid any ambiguities by simply picking the new resolution)
    • super or self (though these aren’t really absolute paths anymore)

(This last point basically deprecates absolute paths starting with top-level items.)

Then, given the “code with no warnings compiles with the same behavior on the next epoch” rule, the next epoch can simply switch to the new resolution rules and deprecate extern crate.

This, again, retains the advantage of less churn than variant 1. Most code will only need to add crate:: to local paths, rather than changing every absolute path.