Stabilize let bindings and destructuring in constants and const fn

[oli-obk]

r? @Centril

This PR stabilizes the following features in constants and const functions:

• irrefutable destructuring patterns (e.g. const fn foo((x, y): (u8, u8)) { ... })
• let bindings (e.g. let x = 1;)
• mutable let bindings (e.g. let mut x = 1;)
• assignment (e.g. x = y) and assignment operator (e.g. x += y) expressions, even where the assignment target is a projection (e.g. a struct field or index operation like x[3] = 42)
• expression statements (e.g. 3;)

This PR does explicitly not stabilize:

• mutable references (i.e. &mut T)
• dereferencing mutable references
• refutable patterns (e.g. Some(x))
• operations on UnsafeCell types (as that would need raw pointers and mutable references and such, not because it is explicitly forbidden. We can't explicitly forbid it as such values are OK as long as they aren't mutated.)
• We are not stabilizing let bindings in constants that use && and || short circuiting operations. These are treated as & and | inside const and static items right now. If we stopped treating them as & and | after stabilizing let bindings, we'd break code like let mut x = false; false && { x = true; false };. So to use let bindings in constants you need to change && and || to & and | respectively.

[cramertj]

I don't see #53515 mentioned here-- isn't this a blocker to stabilization? (or does #56160 somehow gate the problematic behavior?)

[oli-obk]

I don't see #53515 mentioned here-- isn't this a blocker to stabilization? (or does #56160 somehow gate the problematic behavior?)

yes, we're preventing both let bindings and short circuiting operators from being used within the same constant https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=control_flow_destroyed&type=

[cramertj]

I see, e.g. this test here.

[Centril]

Assigning over to:
r? @nikomatsakis
for review of the code changes since I primarily looked at tests.

@cramertj I will write up a stabilization report in a bit either as a separate issue or in this PR and I'll fcp merge that one.

[Centril]

Stabilization proposal

I propose that we stabilize #![feature(const_let)].

@rfcbot merge

Tracking issue: #48821
Version target: 1.33 (2019-01-15 => beta, 2019-03-01 => stable).

What is stabilized

In the following places:

• const fns
• const contexts:
  • array type length expressions
  • repeat expression length expressions (i.e. [expr; length_expr])
  • const, static, static mut item, and enum discriminant initializers

We stabilize:

• expression statements (e.g. 3;)

• irrefutable destructuring patterns; for example:

  let (x, y) = expr;
  const fn foo([x, y]: [u8; 2]) {}

• let bindings including mut ones; for example:

  let x = 42;
  let x: u8;
  let mut x: u8;
  let mut x = 24;

• assignment (e.g. x = y) and assignment operator (e.g. x += y) expressions, even where the assignment target is a projection (e.g. a struct field or index operation like x[3] = 42).

What is not stabilized

• mutable references (i.e. &mut T) and borrows (i.e. &mut x)
• dereferencing mutable references
• refutable patterns (e.g. Some(x))
• operations on UnsafeCell types (as that would need raw pointers, mutable references, and such, not because it is explicitly forbidden. We cannot explicitly forbid it as such values are OK as long as they aren't mutated.)
• We are not stabilizing let bindings in const contexts that use && and || short circuiting operations. These are treated as & and | inside const and static items right now. If we stopped treating them as & and | after stabilizing let bindings, we'd break code like let mut x = false; false && { x = true; false };. So to use let bindings in constants you need to change && and || to & and | respectively.

Divergences from RFC

• See the note above about && and ||. These are control flow operations which should be stabilized in let bindings when we otherwise stabilize && with other control flow in the places aforementioned.
• The RFC does not explicitly mention assignment and expression statements. However, as these are a natural consequence of having let bindings, it might as well be implied.

Tests

The tests can be primarily seen in the PR itself. Here are some of them:

• Array size position
• Enum discriminant position
• Basics
• Macros, expression statements, assignments, etc.
• Not allowing assignment of statics in statics, and another test
• Demonstrating erroring on dropping within constants
• Basic destructuring is permitted
• Assignment to projection, let mut, and with arrays
• Mutable borrows disallowed, and again
• A barrage of tests for assignment ops, assignment, let (mut) bindings, destructuring, projections. This test also checks that the dynamic semantics of what we are stabilizing corresponds to that for fns.
• && and || are forbidden in let bindings in const items
• Dangling pointers handled correctly
• Interior mutability handled correctly, and again, and again
• Promotion

Motivation

From the RFC:

It makes writing const fns much more like writing regular functions and is not possible right now because the old constant evaluator was a constant folder that could only process expressions. With the miri const evaluator this feature exists but is still disallowed.

As for motivations to do this now despite the lack of stable control flow,
given let bindings and assignments we may still:

• Make overflowing_add into const fns on stable.

• Write things such as:

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

History

• Was originally proposed in RFC Allow locals and destructuring in const fn rfcs#2341.

• Implemented in Allow let bindings and destructuring in constants and const fn #49172 by @oli-obk (reviewer = @eddyb).
  Merge date = May 22nd.

• Improved in Allow assignments in const contexts #56070 by @oli-obk (reviewers = @eddyb, @RalfJung)
  Merge date = November 26th.
  This fixed a number of bugs: Regression in #![feature(const_let)] #54098, Wrong error when trying to write to static in a static initializer #51251, and Wrong error with const let #52613.

• Improved in Fix various aspects around let bindings inside const functions #56160 by @oli-obk (reviewers = @Centril, @eddyb, @nikomatsakis, @RalfJung).
  Merge date = December 18th.
  Here we:

  • added a large number of tests.
  • forbade let bindings that contained short-circuiting ops.
  • hardened the analysis code against dereferences of mutable references.

[rfcbot]

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Centril
• @aturon
• @cramertj
• @eddyb
• @joshtriplett
• @nikomatsakis
• @nrc
• @pnkfelix
• @scottmcm
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[scottmcm]

Since we already had ugly let statements by just making another function, I'm glad to see real ones.

[cramertj]

Two clarifications here:

• Why is that we're banning let in combination with && and || rather than making it work? Is there something challenging about implementing the short-circuiting behavior? Or is this just because we haven't yet stabilized const_if?

We are not stabilizing let bindings in const contexts that use && and || short circuiting operations. These are treated as & and | inside const and static items right now.

• "[T]reated as & and |" (which I normally associated with std::ops::BitAnd) just means that they do not yet short-circuit, right?

[Centril]

• Why is that we're banning let in combination with && and || rather than making it work? Is there something challenging about implementing the short-circuiting behavior? Or is this just because we haven't yet stabilized const_if?

@oli-obk knows better than me, but the gist of it is that we haven't implemented match or other control flow yet so it's not even stabilization; on nightly you cannot even write:

#![feature(const_fn)]

const fn foo() {
    match 0 { // error[E0019]: constant function contains unimplemented expression type
        1 => {}
        _ => {}
    };
}

And we can think of && as equivalent to:

match lhs { false => false, true => rhs }

Meanwhile, || can be thought of as:

match lhs { false => rhs, true => true }

I think the main hurdle is just doing the work, which we eventually will, but it will take its time.

• "[T]reated as & and |" (which I normally associated with std::ops::BitAnd) just means that they do not yet short-circuit, right?

Yep, and sadly we already support a buggy, non-short-circuiting, version of && and || in const items but not in const fn; once we do get control flow working in in const eval we can stabilize && and || in const fn as well.

[alexreg]

@oli-obk knows better than me, but the gist of it is that we haven't implemented match or other control flow yet so it's not even stabilization; on nightly you cannot even write:

This is correct. It requires control-flow support, which does not exist whatsoever yet. I'm hoping @oli-obk can pick up where eddyb left off with this. I can help perhaps.

[Centril]

@bors r=nikomatsakis p=1

[bors]

📌 Commit 6c62322 has been approved by nikomatsakis