Rust: Tracking Issue for inline const expressions and patterns (RFC 2920)

[nikomatsakis]

This is a tracking issue for the RFC "Inline const expressions and patterns" (rust-lang/rfcs#2920).
The feature gate for the issue is #![feature(const_expr)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses 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.

Steps

• [x] Implement the RFC (#77124 does most of it, modulo some bugs around range patterns that should be fixed in #78116)
• [x] Adjust documentation (see instructions on rustc-dev-guide) [Unstable Book docs in #78250]
• [ ] Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Naming: "inline const", "const block", or "anonymous const"?
• Lint about &const { 4 } vs const { &4 }?

Implementation history

• Primary implementation PR: #77124
• Unstable Book documentation: #78250

[jhpratt]

With regard to the lint, is there any semantic difference between the two? Intuitively I would expect them to behave identically (static lifetimes).

[RalfJung]

They behave identically. The point of the lint is to have a single "idiomatic" form.

Naming: "inline const", "const block", or "anonymous const"?

The issue title calls it "const expressons" so maybe that should also be on the list.

I prefer "inline const" because it emphasizes that this is a totally separate body of code that is just written inline. That's much more like a closure than normal blocks.

---

Also, is anyone up for implementing this? (I can't even mentor this I am afraid, this affects surface-level syntax and MIR building which is way outside what I know.^^)

[Lokathor]

"const block" is clearly correct.

it matches "unsafe block" that way.

[RalfJung]

That false parallel with "unsafe block" is exactly why it is not correct. An unsafe block inherits scope, execution environment, everything from its parent block. An inline const does not.

[ecstatic-morse]

I'm happy to mentor, although by no means am I an expert on all the parts of the compiler you'll need to touch. There's already an AnonConst type in the AST and the HIR that should for the most part have the same rules as an inline const (e.g. no outside generic parameters), which should make the lowering part of this pretty easy.

If no one volunteers in the next few weeks, I'll try to set aside a day or two to implement this. However, I'm mostly in maintenance/review mode as far as Rust is concerned.

[workingjubilee]

Does const { } differ from normal block expressions, however?
I think either "inline const" or "const expression" should be favored. Everyone's going to call it a constexpr anyways because of C++ user bleedover, and I don't think it's worth offering that much pushback this time. :^)

Hm... I need to fix my computer still. Guess I have a good reason today.

[memoryruins]

Does const { } differ from normal block expressions, however?

const {} does not inherit the same scopes as block expressions do.

Everyone's going to call it a constexpr anyways because of C++

It can be a useful comparison when introducing C++ users to Rust's const and const fn, yet I have not seen most users conflate them. Additionally, C++ does not have constexpr { ... }.

I don't think it's worth offering that much pushback this time.

There are no mentions of constexpr or C++ on this issue before or the RFC. I find it unproductive to label it as pushback from _that_. The concerns about naming are mentioned in the RFC https://rust-lang.github.io/rfcs/2920-inline-const.html and the comments.

[workingjubilee]

Alas, I was trying to make a rather more casual and conversational remark rather than something that I expected to be picked over with a fine-tooth comb and labeled "unproductive". Resolved.

However, when discussing consts, someone literally referred to a similar expression as a "constexpr", to me, today, when they were thinking about trying to write a macro that attempted to implement this feature.

[memoryruins]

I was not responding to the idea of using constexpr unproductive, and I mentioned that the comparison to it can still be useful. I specifically referred to describing current naming discussions as "pushback" to be unproductive. I believe we have had a misunderstanding, and I would be open to discussing this more in a direct message on discord. I do not think we should continue this here.

[spastorino]

@ecstatic-morse I'd like to take this issue if it's not taken yet.

[ecstatic-morse]

Go for it @spastorino!

[spastorino]

I forgot to link this issue from the PR but the PR is now merged https://github.com/rust-lang/rust/pull/77124

[camelid]

I would like to write the documentation.

[spastorino]

I would like to write the documentation.

@camelid please once you have something up cc me so I can review.

[camelid]

Note that right now the feature is named inline-const pretty much everywhere.