Decide on path forward for attributes on expressions (original) (raw)

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