MCP: pub(macro)

[eopb]

Proposal

Summary and problem statement

This idea came from this line of code from the log crate https://github.com/rust-lang/log/blob/master/src/lib.rs#L1441

There is currently no way of keeping a function private while also using them in a public macro. This causes crate developers to resort to warning comments and function name prefixes.

With my feature, functions marked pub(macro) would become public to macros defined in the same crate.

Motivation, use-cases, and solution sketches

With my feature

// WARNING: this is not part of the crate's public API and is subject to change at any time	 
#[doc(hidden)]	 
pub fn __private_api_log(

would become

pub(macro) fn log(

Prioritization

This fits with "Targeted ergonomic wins and extensions". Warning comments and function prefixes do not feel ergonomic.

Links and related work

I understand that hygienic macros could make this feature no longer needed in future. I hope this could act as a smaller, easier to implement incremental step.

rust-lang/rfcs#2968

Initial people involved

TBD

What happens now?

This issue is part of the experimental MCP process described in RFC 2936. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open MCPs in its weekly triage meetings. You should receive feedback within a week or two.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[nikomatsakis]

Summary of comments from Zulip thus far:

• The problem is real and well-motivated.
• However, there are significant concerns about implementation complexity.
• The syntax is a bit odd, since pub(macro) is really a "visibility" in the same sense as today's language (i.e., it doesn't specify a visibility to a particular module).

[nikomatsakis]

We discussed this in our meeting today. Based on that discussion I'm putting this in final comment period with disposition to close (for now...).

The general sense was that this was solving a real problem, but we tended to agree with @petrochenkov that the syntax itself wasn't really making the problem much easier. In other words, we would still need to have a solution to the "hygiene challenge" of giving macro-generated code access to items based on the location of the macro that generated it, and it's not clear that declaring such items as pub(macro) makes this especially easier (and it's also not clear that we would want such a syntax except to aid in the implementation). This isn't to say, I think, that anybody was opposed to some syntax if it was useful.

More generally, it feels like we clearly need a hygiene / macros-2.0 project group to chase down these designs. But this is a longstanding issue where we don't presently have the bandwidth available (and it would require some amount of core lang-team involvement, I believe, as well as experts like @petrochenkov).

Thanks to @ethanboxx for the proposal. ❤️

[eopb]

Sounds like a sensible decision.

If and when the bandwidth for a hygiene / macros-2.0 project group is available it would be cool to be involved.

Thank you for discussing my proposal.

[nikomatsakis]

Check-in from the lang-team meeting:

• We are going to close this proposal per prior move.
• But we agree that the problem needs to be solved and will add a note to the 'shortlist' section to encourage us to revisit it if/when bandwidth becomes available.