Tracking Issue for inline const patterns (RFC 2920)

[nikomatsakis]

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

• Implement the RFC (Implement const expressions and patterns (RFC 2920) #77124 does most of it, modulo some bugs around range patterns that should be fixed in Make inline const work in range patterns #78116)
• Adjust documentation (see instructions on rustc-dev-guide) [Unstable Book docs in Document inline-const #78250]
• Handle inner attributes. Parse inner attributes on inline const block #94985
• Decide whether Non-terminals, e.g. expr, have diverged between parser and macro matcher #86730 needs to be resolved.
  • Lang decided in 2024-04-03 triage that this is not a blocker.
• Parsing bug inside let-else: Let-else not checking for curly brace of inline const before else #118859
• Resolve Const-eval errors in dead functions are optimization-dependent #107503
• Decide whether Which functions are "reachable", and therefore subject to monomorphization-time checks, is optimization-dependent #122814 needs to be resolved
  • Lang decided in 2024-04-03 triage that this is not a blocker.
• Decide whether Evaluating constants in MIR optimizations introduces const eval errors  #122828 needs to be resolved
  • Lang decided in 2024-04-03 triage that this is not a blocker.
• Stabilization PR: expressions Stabilise inline_const #104087
• Reference PR: Document inline const/const block expression reference#1295
• Stabilization PR: patterns

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

[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.

[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 #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.

[tgross35]

Can this be closed with #104087?

[jhpratt]

@tgross35 patterns are still unstable, so no.

[RalfJung]

What are the remaining blockers and other TODO items for inline const patterns?

[lolbinarycat]

one thing i thing this is helpful for: allowing use withing patterns. this is expecially useful in the context of macros that expand into patterns.

for example, if we want to match against a variant of a certain enum, is it possible to expand to const { use Enum::*; $v }?

[herabit]

I have no clue how this whole "contributing to a major open source project" thing works, however, I'm curious about the progress of this feature.

It would make pattern matching with the newtype pattern (namely newtypes that have some invariant that must be upheld)
so much easier.

An example would be the ascii crate. As of now the crate does not currently expose any functionality for creating ASCII strings
at compile time, though for simplicity this will be overlooked as this would be trivial to add.

But let's say you're working with some format that must only work with ASCII strings, so you pull in the ascii crate. With this feature you could trivially match on keywords with something like:

macro_rules! ascii {
     ($e:expr) => {const {
           let x = $e;

           match ::ascii::AsciiStr::new_const(x) {
                  Some(x) => x,
                  None => panic!("not an ascii string"),
           }
    }};

}

fn is_keyword(s: &AsciiStr) -> bool {
       match s {
              ascii!("continue") => true,
              ascii!("break") => true,
              _ => false,
       }
}

This is just an example and there are many such cases where something like this would be really useful.

[TomerPelleg]

I would also like to support this feature, for a very simple use-case.

I would like to do something like:

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

And this feature allows me to do (currently only at nightly):

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

By the way, will future versions allow the omitting the "const" keyword in cases where the pattern is a const expression (such as this example)?

[lcnr]

feature(inline_const_pat) results in some quite non-trivial implementation challenges. We therefore intend to remove the implementation of this feature in #138492 until we're able to resolve them.

[Qix-]

Huge setback, then :/ This makes certain ergonomics of some of the code I'm working on much easier, and removing what little support is there means I'll have to resort to a proc macro.

Is there any way to keep what's there for now, even if things must be marked excessively with unstable features etc?

[zeroflaw]

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.

[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 :|

[RalfJung]

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.