(Modules) Tracking issue for `(use) crate_name::` paths without `extern crate`

[Centril]

This is a sub-tracking issue for the RFC "Clarify and streamline paths and visibility" (rust-lang/rfcs#2126)
dealing with the deprecation of extern crate as well as having use crate_name::foo::bar and crate_name::foo::bar Just Work™.

• Implement the RFC.
  • The main blocker is that we don't yet have the macro changes finalized to make it possible to avoid needing #[macro_use] extern crate.
    • See Implement #[macro_export(local_inner_macros)] (a solution for the macro helper import problem) #51496
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

None

[joshtriplett]

I feel that the deprecation of extern crate and the automatic inclusion of external crates in the prelude has gotten enough exposure and positive feedback that it's ready for us to commit to as the path we're going down. We shouldn't stabilize it until we stabilize the macro system changes, but we can handle that via a blocking concern; in the meantime, let's confirm that we have consensus.

Note that while we're still talking about the final system for paths in use statements, both of the proposals currently under consideration incorporate this deprecation of extern crate and automatic inclusion of external crates in the prelude.

@rfcbot fcp merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged teams:

• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @withoutboats

Concerns:

• macros resolved by (Modules) Tracking issue for (use) crate_name:: paths without extern crate #53128 (comment)
• no_std-std resolved by (Modules) Tracking issue for (use) crate_name:: paths without extern crate #53128 (comment)

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[joshtriplett]

@rfcbot concern macros

We shouldn't stabilize this until we first stabilize the macro system changes needed to deprecate #[macro_use] extern crate as well.

[matklad]

Not really a concern, but some tradeoffs about automatic inclusion of external crates in the prelude, mostly from internals thread.

In Rust 2015, there are two ways to refer to extern crate foo:

• add use foo to the top of the file and write foo::Bar in the module's body (special case in the root: extern crate instead of use).
• write ::foo::Bar in the module body

Extern crates in prelude adds a third one:

• write foo::Bar in the module body

This third variant is easier to type, but it gives the least amount of information to the reader.

• With the first option, two readability properties are maintained. It is possible to use text search in a single file to see where the foo identifier comes from. By looking at the list of imports, it is possible to say, based on the imported crates, what the module could do, without reading its source.
• With the second option, it is immediately clear where the foo comes from, especially in 2018 edition, although it's not possible to scan a list of imports to get an "overview" of the module dependencies.
• With the the third option, neither text search, not dependencies overview work. Although the set of extern crates is usually not very big, it is project specific, so, seeing a foo::bar in an unfamiliar code base, it might be not trivial to understand where the foo comes from.

It is also seems to be the case that adding extern crates to the prelude is not required to make other module systems changes "work". Specifically, ergonimics is not regressed compared to Rust 2015: ::foo::Bar style paths continue to work. use foo; foo::Bar pairs continue to work, extern crate foo; foo::Bar pair changes to use foo; foo::Bar. The only exception here is std in the root module, whose extern crate std is added implicitly. This is mitigated by the fact that popular types of std are in prelude and that std does not contain top-level items, so submodules are often usually imported anyway.

It is true that some use statements might be dropped with this feature in 2018.

The original motivation for this feature was to fix path confusion: the fact that paths in use statements and everywhere else work differently. This is only a partial fix though:

• use foo::Bar and foo::Bar in fn body will resolve to the same Bar, but for different reasons: in the first case, because the path is equivalent to ::foo::Bar, in the second case, because foo is in prelude.
• This does not solve the problem of needing self:: in use to refer to submodules and local enums, and there's a separate proposal to fix that.

TL;DR

extern crates in prelude

• seem to violate "optimize for the reader" rule,
• are not necessary to make 2018 systems coherent (and could be added in the next edition),
• don't quite solve the original problem they were a solution for.

[sanmai-NL]

@matklad: your critique ultimately hinges on the outcome of #53130, no? AFAICT, the ambiguity does not appear if we choose anchored_use_paths there.

[matklad]

#53130 is about paths in use statements. The addition of crates to prelude affects paths outside of use statements. I.e., even with anchored_use_path (which is what currently is default with edition 2018 I believe), fn main() { regex::Regex::new(".*").unwrap().expect() } works.