Tracking Issue for inline const patterns (RFC 2920)

This is a tracking issue for the RFC "Inline const expressions and patterns" (rust-lang/rfcs#2920).
Const expressions have been stabilized, but patterns have not
The feature gate for the issue is #![feature(inline_const_pat)].

This was originally a tracking issue for const blocks in both expression and pattern position. Inline const expressions have been stabilized in #104087 while patterns are still unstable.

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

Unresolved Questions

Naming: "inline const", "const block", or "anonymous const"?
Lint about &const { 4 } vs const { &4 }?
How should this work for the special has-block syntax rules? https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453

Implementation history

Primary implementation PR: Implement const expressions and patterns (RFC 2920) #77124
Unstable Book documentation: Document inline-const #78250
FnDef type is disallowed in patterns: Deny FnDef in patterns #114668

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

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.^^)

"const block" is clearly correct.

it matches "unsafe block" that way.

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.

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.

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.

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.

Rollup merge of rust-lang#138492 - lcnr:rm-inline_const_pat, r=oli-obk

Auto merge of rust-lang#138492 - lcnr:rm-inline_const_pat, r=oli-obk

Anyone that is refactoring today, another way to get a const inline without the inline_const_pat feature is:

fn main() {
    let x: usize = 1;
    match x {
         0 => println!("x is zero"),
         const{0+1}=> println!("x is one"),
         _ => println!("x is neither 0 or 1")
    }
}

becomes:

fn main() {
    let x: usize = 1;
    match x {
         0 => println!("x is zero"),
         v if v == const{0+1}=> println!("x is one"),
         _ => println!("x is neither 0 or 1")
     }
}

The downside of the above is you can't "~const" PartialEq on a non-primitive type, like you could before. So you might need to implement a const_eq function so you can do:

v if v.const_eq(const { &Self::const_zero() }) => println!("x is zero"),

Hope this helps someone.

The downside to that is that you cannot generalize that to an expression form.

const SOME_KEY = key!("...");

match SOME_KEY {
    key!("...") => { ... },
    key!("???") => { ... },
}

There's no way to write key!() in a way where that's usable in all expression contexts without this feature :|

The LHS of => is not an expression, it's a pattern. So what you are asking is for the same term to work both as a pattern and as an expression.

Yeah that does not work without const patterns, true.

Auto merge of rust-lang#138492 - lcnr:rm-inline_const_pat, r=oli-obk

@Qix-

The downside to that is that you cannot generalize that to an expression form.
const SOME_KEY = key!("...");

match SOME_KEY {
    key!("...") => { ... },
    key!("???") => { ... },
}
There's no way to write key!() in a way where that's usable in all expression contexts without this feature :|

@Qix-, there is, thanks to adt const params. Well, the example below actually requires unsized const params for the &str parameter whose future is unclear but in most other cases you wouldn't need it. I'm using generic const items (GCI, #113521) for convenience but they're not strictly necessary.

#![feature(const_trait_impl, const_cmp)]
#![feature(adt_const_params, unsized_const_params)]
#![feature(generic_const_items)]
#![expect(incomplete_features, reason = "generic_const_items,unsized_const_params")]

const KEY_OF<const STR: &'static str>: i32 = match STR {
    "..." => 0,
    "???" => 1,
    _ => panic!("unsupported"),
};

macro_rules! key { ($str:expr) => { KEY_OF::<{ $str }> } }

const SOME_KEY: i32 = key!("...");

const _: () = match SOME_KEY {
    key!("...") => {}
    key!("???") => {}
    _ => panic!("unsupported"),
};

It's more restricted, of course, but at least there is a way to express basic forms of this.

Without GCI:

#![feature(const_trait_impl, const_cmp)]
#![feature(adt_const_params, unsized_const_params)]
#![expect(incomplete_features, reason = "unsized_const_params")]

struct Owner<const STR: &'static str>;

impl<const STR: &'static str> Owner<STR> {
    const KEY_OF: i32 = match STR {
        "..." => 0,
        "???" => 1,
        _ => panic!("unsupported"),
    };
}

macro_rules! key { ($str:expr) => { Owner::<{ $str }>::KEY_OF } }

// ...

sys: Fix build error on nightly-2024-04-19

Inline const patterns have been entirely removed from the compiler due to significant technical limitations. readding them should require a separate proposal. Closing

Auto merge of #138492 - lcnr:rm-inline_const_pat, r=oli-obk

Navigation Menu

Repository navigation

Tracking Issue for inline const patterns (RFC 2920) #76001

About tracking issues

Steps

Unresolved Questions

Implementation history

138 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for inline const patterns (RFC 2920) #76001

Description

About tracking issues

Steps

Unresolved Questions

Implementation history

Activity

jhpratt commented on Aug 28, 2020

RalfJung commented on Aug 29, 2020

Lokathor commented on Aug 29, 2020

RalfJung commented on Aug 29, 2020

ecstatic-morse commented on Aug 29, 2020

workingjubilee commented on Sep 1, 2020

memoryruins commented on Sep 1, 2020

workingjubilee commented on Sep 1, 2020

memoryruins commented on Sep 1, 2020

138 remaining items

zeroflaw commented on Apr 2, 2025

Qix- commented on Apr 3, 2025

RalfJung commented on Apr 3, 2025

fmease commented on Dec 6, 2025

lcnr commented on Feb 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions