Tracking issue for pub(restricted) privacy (RFC #1422)

[nikomatsakis]

Tracking issue for rust-lang/rfcs#1422

RFC text

Milestones:

• Implemented (PR Implement pub(restricted) privacy (RFC 1422) #32875)
• Decided to stabilize
• Update syntax Update syntax for pub(restricted) #40340
• Documented in the rust manual document pub(restricted) syntax #40334
• Stabilization PR -- see mentoring instructions below
• Stabilized

[jonas-schievink]

You probably meant rust-lang/rfcs#1422

[nikomatsakis]

@jonas-schievink indeed. :)

[petrochenkov]

How to parse struct S(pub (std::marker::Send + std::marker::Sync));? It's currently legal.

If we try to parse std::marker::Send as a part of pub(restricted) based on is_path_start(std) == true, then we end up in the middle of a type sum after parsing an arbitrary number of tokens with only a Path in hands and need to recover.

Similar cases with simpler disambiguation:

struct Z(pub (u8, u8));
struct W(pub (u8));

Note that pub(path) is a strict subset of pub TYPE (modulo pub(crate)), so the former can be parsed as the latter and reinterpreted later if necessary.

I suppose everything here can be disambiguated, but I'm concerned about the conflict pub(path) vs pub TYPE in general and how it affects formal properties of Rust grammar.

[nikomatsakis]

@petrochenkov sigh. a very good point. @pnkfelix and I were chatting-- one obvious (but not particularly appealing) option would be to say that tuple structs just can't use pub(restricted) paths. This would be better if we had the notion that one could write struct Z { pub 0: (u8, u8) } to use the more explicit name.

We considered various other synaxes one could use:

• pub{path}
• pub(in path)
• pub in path

One consideration is that I expect most people will want to either make fields pub -- meaning, as public as the struct itself -- or private. So perhaps it's ok that you can't use tuple structs to express more flexible things -- they're kind of a convenience shorthand as is. But it is unfortunate however you slice it.

[Stebalien]

For reference, @nikomatsakis is referring to #1506.

[nikomatsakis]

On Sun, Apr 3, 2016 at 5:52 AM, Vadim Petrochenkov <notifications@github.com

wrote:

Note that pub(path) is a strict subset of pub TYPE (modulo pub(crate)),
so the former can be parsed as the latter and reinterpreted later if
necessary.

Hmm, I suppose that's true. (Or might be true)

[nikomatsakis]

So in the @rust-lang/lang meeting we discussed this problem, as well as the solution implemented in #33100. Our conclusion was that we really ought to explore the cover grammar approach described earlier by @petrochenkov here:

Note that pub(path) is a strict subset of pub TYPE (modulo pub(crate)), so the former can be parsed as the latter and reinterpreted later if necessary.

It is basically the only approach that lets restricted paths and tuple structs be fully integrated, without any artificial restrictions (like needing to convert to {} form, or needing to introduce an extra set of parens). It's a shame that the most natural grammar would no longer be LL(k) (nor LR(k)), but given that such an obvious cover grammar exists, that shouldn't cause a lot of problems in practice.

[nikomatsakis]

The ambiguous syntax has come up some more on rust-lang/rfcs#1575, where it interferes with the idea of having a "visibility matcher". Some proposals were made for alternative syntax options there:

• pub{path}
• pub@path
• pub(in path)

Most of these were covered (and rejected) in my prior comment, but it is true that the lookahead requirement is onerous.

[Stebalien]

We could always just use another keyword (scope, scoped, restrict, restricted, vis, etc...):

• restricted(path)
• restricted path

And all related variants...

[cramertj]

Just to clarify with everyone: super is a path, so both pub(super) and pub(in super) are valid?

[withoutboats]

Yes

[cramertj]

This probably shouldn't have been closed since the documentation hasn't landed yet.

[steveklabnik]

I believe this is only waiting on docs, and I believe all the docs have made it. Can this be stabilized?

[petrochenkov]

This was stabilized a month ago, the only remaining bit is the Rust-by-example PR that's not merged yet.
I think it's time to close this.

[steveklabnik]

Ah excellent; I was going to say, sad if it had just missed a release.

[cramertj]

I thought it did miss the release-- it was beta nominated for a bit, but that got cancelled IIRC.

[cramertj]

Just checked in the playground-- it stabilizes in 1.18.