Tracking Issue for item-level `const` blocks

[GrigorenkoPV]

There has been no RFC, afaict. However, t-lang have expressed enthusiasm about seeing this added.
The feature gate for the issue is #![feature(const_block_items)].

Currently, this feature allows you to write const blocks as items in modules. So, it makes the following code possible:

#![feature(const_block_items)]

const {
    let a = 2 + 2;
    assert!(a != 5)
}

fn main() { }

Which is equivalent to the current stable's:

const _: () = {
    let a = 2 + 2;
    assert!(a != 5)
};
fn main() { }

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

See also

• Lang discussion: Item-level const {} blocks, and const { assert!(...) } lang-team#251
• Zulip: #t-lang > item-level const blocks
• Zulip: #t-lang > inline static expressions

Steps

• Implementation (see at the very bottom)
• Adjust documentation (see instructions on rustc-dev-guide)
• Style updates for any new syntax (nightly-style-procedure)
  • Style team decision on new formatting
  • Formatting for new syntax has been added to the Style Guide
  • (non-blocking) Formatting has been implemented in rustfmt
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• RFC needed?
• it has been decided that module-level const { ... } item is equivalent to const _: () =, but what about statement-items (i.e. inside function body) or assoc items?
• Making const { ... } sometimes an item and sometimes an expression complicates our story about that.
  • Other possibilities would be things like const _ = ...; to clarify that it's an item, but shorten the syntax (like one can omit -> () on functions) nobody was too enthusiastic about this approach: see Ability to omit : () on const item declarations #149738
• The diagnostics for module-level const block items are subpar, and could benefit from
  • mentioning that the return type of the block is expected to be ()
  • actually having the phrase "const block item" in messages instead of "malformed const"
  • not leaking the dummy _ identifiers that are inserted during AST->HIR lowering of const { ... } to const _: () = const { ... };
  • rejecting visibility qualifiers on module-level const block items, since those have no effect (see also: Add warn-by-default lint for visibility on const _ declarations #147136)
• module-level const block items currently reject inner attributes during parsing. Is this the desired behavior?
• maybe use static { ... } instead of const { ... }?

Implementation history

• Module-level const blocks: const blocks as a mod item #149174
• Ability to omit : () for const items: Ability to omit : () on const item declarations #149738

[tgross35]

Could you add a small summary and demo to the issue? It's not clear what this is about or what it is supposed to look like without doing a bit of digging in the implementation PR.

[scottmcm]

I continue to have a concern with doing this because we give very different guarantees for what happens in a mod-level const = and in a fn-level const { ... }. It would be a big footgun -- and completely inconsistent with other items -- if moving an item into a function changed it to do something materially different.

We discussed the related #149738 in the lang triage meeting today, and the overall vibe was that we would still like something better than const _: () =, so hopefully someone has a bright idea for what a "there's still a syntactic distinction between item and expression" (like how fn-vs-closure is different, for example) should be.

Niko has started #t-lang > item-level const blocks @ 💬 on zulip to discuss that, so if you have good ideas, please join us there!