Naming and rationale of crate visibility modifier

[Riateche]

The Path clarity RFC says:

Rather than using crate as a visibility specifier, we could use something like local. (If we used it purely as a visibility specifier, we could make it a contextual keyword). That might be preferable, since local is an adjective and is arguably more intuitive. This is an unresolved question.

What is the exact status of this question? The RFC pull request discussion barely touches this topic. I couldn't find any other disscussions related to it. What is the rationale behind replacing pub(crate) with crate?

It may be that it's just a novelty thing and everyone will get used to it eventually, like everyone got used to C++'s protected. However, right now it just seems scary that Rust will get this change. crate as a visibility modifier is not readable and not intuitive. crate X means "X is a crate" for me. While it's true that the syntax is unambiguous and you can tell that it's a type or a field and not a crate, overall this change makes Rust code harder to understand, especially to newcomers. I imagine it can ultimately result in questions like "what is a crate in Rust? Judging by the code, types and fields can also be crates".

I understand that choosing a better name and making a contextual keyword for it may take more work. However, just using a vaguely related existing keyword doesn't seem like a reasonable way to go at all. So if making a new contextual keyword is not desired right now, why not just stick with pub(crate)? When it was introduced, I didn't feel any confusion. It was immediately clear what it does. What benefit does crate have over pub(crate)? Is it worth the additional confusion and entry barrier?

[johnthagen]

See also the comments on the tracking issue: https://github.com/rust-lang/rust/issues/44660

[kornel]

There was a 300-comment discussion about the these keywords: https://github.com/rust-lang/rfcs/pull/2126 and earlier long thread https://github.com/rust-lang/rust/issues/32409

[ExpHP]

That said, as much as I have been looking forward to both new meanings of the crate keyword, I find @seanmonstar’s testimony (1, 2) on the tracking issue to be compelling. Now that we have people really trying the feature out in earnest, they are discovering examples that are unexpectedly tough to parse mentally.

[kornel]

Yeah, the crate crate:: examples look a bit odd.

I was going to just keep using pub, but I’ve just learned that there will be a warning about unreachable pub, so now I’m not liking that too

[johnthagen]

I’ve read enough of these testimonials, which are basically “I don’t like it, so I’ll probably not use it”, that I worry this feature will fracture what it means to write idiomatic Rust in this area.

I also had the same initial reaction when I migrated a binary app.

[Centril]

Personally, I’m finding that the length of pub(crate) is contributing too much to my function signatures (which are already too long) and so I am discouraged from making things crate-local and might opt for pub fn instead. Thus, I’m excited about crate fn being a thing and thereby improving ergonomics and readability.