Decide on path forward for attributes on expressions

[traviscross]

Long ago, we adopted rust-lang/rfcs#16 ("attributes on statements and blocks"). However, it's long been blocked despite the known and compelling use cases for this.

Over in the tracking issue, #15701, @WaffleLapkin explains the nature of what is blocking this and proposes a path forward:

From what I understand the issue blocking this is ambiguity -- even if the RFC specifies what #[meow] 1 + 1 means, it's still not very readable. I think the path forward is to cut this feature to only allow attributes on things that are unambiguous, such as:

• All kinds of braces: #[meow] (1 + 1), #[uwu] [1, 2, 3], #[purr] {} (parethesis/grouping expr, tuples, arrays, blocks)
• Closures: #[kwncjhn] || 2
• Expressions starting with a keyword: #[meow] if x {}, #[attr] loop { break 'rust; }, #[kva] while false {}, ...
• etc

Then we can provide a suggestion to add parenthesis around the expression, if it is not supported:

error: meow meow meow ambiguous attribute
 --> src/main.rs:LL:CC
   |
LL |     let x = #[meow] 1 + 1;
   |
help: wrap the expression in parenthesis
   |
LL |     let x = #[meow] (1 + 1);
   |                     +     +
help: wrap the expression in parenthesis (alternative
   |
LL |     let x = (#[meow] 1) + 1;
   |             +         +

Let's nominate this for discussion so we can decide whether we can unblock this by adopting that proposal.

This may have relevance for whether libs-api would feel the need to stabilize this:

• Tracking issue for core::hint::must_use #94745

@rustbot labels +I-lang-nominated +T-lang +C-discussion

cc @rust-lang/lang @WaffleLapkin

Tracking:

• Tracking issue for stmt_expr_attributes: Add attributes to expressions, etc. #15701

[scottmcm]

We had a short discussion about this in the lang triage meeting today.

We'd like to unblock progress here, but I had some concerns that I thought Tyler did a good job of phrasing: there might be a different between technically unambiguous and socially unambiguous. I'd thus like to propose making a partial step, and potentially coming back later with additional motivation for more places if needed.

Proposal: We stabilize attributes on closures and on blocks, like these

let _x = #[foo] || 0;
let _y = #[foo] { 4 };
let _z = { #![foo] 2 };

@rfcbot fcp merge

(Noting that attributes on statements are already stable.)

[rfcbot]

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

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• consider-handling-of-cold (Decide on path forward for attributes on expressions #127436 (comment))
• macros-in-lists (Decide on path forward for attributes on expressions #127436 (comment))
• we-should-figure-this-out-better (Decide on path forward for attributes on expressions #127436 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

@rfcbot reviewed

In favor of taking an incremental step here.

[petrochenkov]

Proposal: We stabilize attributes on closures and on blocks, like these

Do you plan to stabilize any attributes in list contexts like

call(#[foo] { block1 }, #[bar] { block2 })

?
(Macro attributes in particular.)

In any case I'll need to audit the technical details before any stabilization is merged, please ping me if necessary.
(Can't do it right now, unfortunately.)

[scottmcm]

@petrochenkov Are you thinking of that in terms of whether cfgs on those can remove the expressions from the list? Or is it something else? (I'm not familiar with the gotchas for these things, so I could easily be missing something.)

[petrochenkov]

It needs to be decided how proc macros see the commas, or other separators in similar cases.

Ideally proc macros should be able to turn 1 expression into multiple (including 0) expressions in this position, similarly to cfgs or macros in list contexts without separators.
So it would be reasonable if the separators were included into both input and output tokens streams (there are probably other alternatives, but they do not fit into the token-based model as well).
The "reparse context" bit from #61733 (comment) is likely relevant to this case as well.

[joshtriplett]

@scottmcm For closures with keywords in front of them (e.g. move), are you proposing exclusively #[attr] move || ... or also move #[attr] || ...? I'd assume the former and not the latter.