Tracking issue for RFC 2341, Allow locals and destructuring in const fn

[Centril]

This is a tracking issue for the RFC "Allow locals and destructuring in const fn" (rust-lang/rfcs#2341).

Steps:

• Implement the RFC (cc @oli-obk - just remove the few checks)
• Adjust documentation (Document const_let reference#506)
• Stabilize (proposal: Stabilize let bindings and destructuring in constants and const fn #57175 (comment))
• Fix short-circuiting operators Wrong result after short circuit in const_let #53515 (no longer compiles on nightly -- Wrong result after short circuit in const_let #53515 (comment))

Unresolved questions:

None.

[eddyb]

just remove the few checks

It's a bit trickier, because rustc_mir::transform::qualify_consts needs to track local variables just like it does only temporaries right now, but it shouldn't

Also, was let in other const contexts in the RFC, i.e. const X: i32 = { let x = 2 + 3; x * x};?

[Centril]

@eddyb Feel free to edit the issue description =)

Also, was let in other const contexts in the RFC, i.e. const X: i32 = { let x = 2 + 3; x * x}; ?

Yes, because (quoting the summary):

Allow let bindings in the body of constants and const fns. Additionally enable destructuring in let bindings and const fn arguments.

[bstrie]

A question about the "Drawbacks" section from the original RFC:

You can create mutable locals in constants and then actually modify them. This has no real impact on the constness, as the mutation happens entirely at compile time and results in an immutable value.

Can you elaborate on this? Is this just referring to something like const foo: i32 = { let mut x = 0; x += 1; x };? That's my straightforward reading of the text, but it also seems completely expected so I'm not sure whether there's a more pernicious drawback I ought to be seeing.

[oli-obk]

Not a drawback really, but a note that this is new behaviour, because before you could never modify the same memory twice, only emulate the same program behaviour via const fn.

[oli-obk]

This works now on nightly (behind a feature gate). Please play around with this feature liberally and report any findings! Any help in documenting and pushing it over the stabilization line is appreciated.

[oli-obk]

Imo it would be fine if added behind its own feature gate. So if you're looking for something easy to do:

1. add a new feature gate (just search for const_let and copy all the defining parts)
2. wrap https://github.com/rust-lang/rust/blob/master/src/librustc_mir/transform/qualify_consts.rs#L276 in a feature gate check (so if the feature gate is active, then that line needs to be not called)
3. Add regression tests

[dtolnay]

Short-circuiting operators need to be fixed before stabilizing const_let. Otherwise it is possible to observe wrong results when changing a fn to const fn. #53515

[oli-obk]

I already added it to the OP ;)

[oli-obk]

We could stabilize let bindings in const fn (but not in const/static), because const functions do not have the issue that && and || short circuit (since these operations are illegal in const functions until control flow in general is allowed).

Due to backwards compatibility constraints we cannot make && and || illegal in constants and statics.

cc @Centril

[Centril]

@oli-obk Hmm... there are a bunch of bug reports cited in #48821 (comment)... we'd have to feel comfortable with the implementation before stabilizing.

However, my main question re. stabilizing is whether stabilizing let without control flow would bring much benefit without any control flow? What is it that we "unlock" by stabilizing in const fn only?

[oli-obk]

I have a fix ready for these bugs in #56070

However, my main question re. stabilizing is whether stabilizing let without control flow would bring much benefit without any control flow? What is it that we "unlock" by stabilizing in const fn only?

You can do things like

fn bar() -> [u32; 500] {
    let mut foo = [0; 500];
    foo[3] = 42;
    foo
}

Or just generally make your code more readable in case the return expression is very complex.

[Centril]

@oli-obk

I have a fix ready for these bugs in #56070

Cool. :)

Or just generally make your code more readable in case the return expression is very complex.

I somehow doubt expressions can become complex without any sort of control flow but I suppose it doesn't hurt. Clearly enough time has passed since it was landed in nightly...

Could you? prepare:

1. a special new issue or alternatively a stabilization PR (the latter is my preference)
2. with a report that points out:
   0. when the initial implementation landed in nightly
   1. relevant tests
   2. what exactly is being stabilized
   3. what is not being stabilized
      1. and why
   4. any divergences from the RFC (there are such because of c) )
3. change this tracking issue with a checkbox pointing out the remaining work after the initial stabilization

[mjbshaw]

Does this tracking issue include mutable references? Or is that a separate RFC/tracking issue?

[oli-obk]

Mutable references require their own full rfc imo. There are so many edge cases. I have started tracking some in rust-lang/const-eval#16

[Centril]

Stabilization proposed: #57175 (comment)

[Centril]

Stabilized in #57175; Documentation issue: rust-lang/reference#506

Everything is done so closing therefore.