Rebalacing macro_metavar_expr to allow stabilization

[c410-f3r]

Too small to be a RFC and too complicated to be a PR. I guess this is the best place but if not, feel free to suggest another location.

Proposal

macro_metavar_expr is an approved feature that unfortunately created divergent opinions after its acceptance, which ended up blocking stabilization.

In hopes of making some progress, two approaches based on the feedback provided so far will be proposed here.

1. Innermost vs Outermost indexes

count uses outermost indices while length uses innermost indices and this inconsistency creates unnecessary confusion.

To improve the situation, the order of all elements should start from the innermost index to the outermost index.

Mentions

• Tracking Issue for RFC 3086: macro metavariable expressions rust#83527 (comment)
• Tracking Issue for RFC 3086: macro metavariable expressions rust#83527 (comment)
• Tracking Issue for RFC 3086: macro metavariable expressions rust#83527 (comment)
• Tracking Issue for RFC 3086: macro metavariable expressions rust#83527 (comment)
• Tracking Issue for RFC 3086: macro metavariable expressions rust#83527 (comment)
• Tracking Issue for RFC 3086: macro metavariable expressions rust#83527 (comment)

2. $ prefix

Taking count as an example, should the syntax be count(some_metavariable) or count($some_metavariable)? The original RFC specified that metavariable expressions should refer metavariables without $ prefixes but there were some arguments in favour of $.

For unblocking purposes, the requirement of $ is being proposed. Such enforcement doesn't appear to incur a significant overhead besides the additional typing and interactions with $$ or multiple $$s shouldn't be a problem as long as the final expanded $ refers a metavariable.

Mentions

• Stabilize $$ in Rust 1.63.0 rust#95860 (comment)
• Stabilize $$ in Rust 1.63.0 rust#95860 (comment)
• Stabilize $$ in Rust 1.63.0 rust#95860 (comment)
• Stabilize $$ in Rust 1.63.0 rust#95860 (comment)
• https://internals.rust-lang.org/t/macro-meta-functions/16743
• https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/macro.20metafunctions.20vs.20eager.20expansion

Mentors or Reviewers

@c410-f3r

Process

The main points of the [Major Change Process][MCP] are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

[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.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[Noratrieb]

I don't think a compiler MCP is the right place for this. I think you're right that it's not an RFC either. Perhaps just an IRLO thread or a lang zulip thread or on a separate issue?

[c410-f3r]

Closing per the above comment. I will then try in the tracking issue.