Acknowledge that [CONST; N] is stable

[RalfJung]

When const_in_array_repeat_expressions (RFC 2203) got unstably implemented as part of #61749, accidentally, the special case of repeating a constant got stabilized immediately. That is why the following code works on stable:

const EMPTY: Vec<i32> = Vec::new();

pub const fn bar() -> [Vec<i32>; 2] {
    [EMPTY; 2]
}

fn main() {
    let x = bar();
}

In contrast, if we had written [expr; 2] for some expression that is not literally a constant but could be evaluated at compile-time (e.g. (EMPTY,).0), this would have failed.

We could take back this stabilization as it was clearly accidental. However, I propose we instead just officially accept this and stabilize a small subset of RFC 2203, while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline const expressions (to avoid relying too much on implicit promotion), so it could take a bit until it comes to full fruition. [CONST; N] is an uncontroversial subset of this feature that has no semantic ambiguities, does not rely on promotion, and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them, possibly using associated consts if generics are involved).

Well, I said "no semantic ambiguities", that is only almost true... the one point I am not sure about is [CONST; 0]. There are two possible behaviors here: either this is equivalent to let x = CONST; [x; 0], or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if CONST has a destructor, it should run in the former case (but currently doesn't, due to #74836); but should not run if it is considered a NOP. For regular [x; 0] there seems to be consensus on running drop (there isn't really an alternative); any opinions for the CONST special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all, the let-expansion does not work in general, for N > 1.

Cc @rust-lang/lang @rust-lang/wg-const-eval
Cc #49147

[rust-highfive]

r? @matthewjasper

(rust_highfive has picked a reviewer for you, use r? to override)

[matthewjasper]

r=me with lang team sign-off

[RalfJung]

Regarding dropping, I now added a test to make sure that [CONST; 0] does not call the destructor. The reasoning is that [CONST; N] should instantiate the const and then later call the destructor exactly N times.

This is in contrast to [non_const_expr; N] which always evaluates the expression exactly once, and thus calls the destructor exactly once (with #74836 fixed). Note that there being a destructor implies !Copy and thus N <= 1.

[scottmcm]

We discussed this in the lang team meeting today and decided to go ahead and

@rfcbot fcp merge

---

I agree that we might as well just allow this to work for something that's just the ident (well, a path) of a const. As you mentioned, we'll want [const { EMPTY }; 2] to work at some point, and it seems fine for this specific case to allow it without the extra const{} -- it feels kinda weird to have to put it around something that's already a const anyway.

[rfcbot]

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

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.

[RalfJung]

@scottmcm

We discussed this in the lang team meeting today and decided to go ahead and

Did you have a chance to talk about the issue with [expr; 0] that I described above?

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[scottmcm]

@RalfJung we discussed this again today in the triage meeting, and agreed that [CONST; 0] not instantiating the const made sense, as consistent with other lengths as you described above.

---

Another piece of that which came to mind today is that since [CONST; 0] must be a const item, then if it panics in evaluation then it'll give a const_err warning on the item. AKA it'll be evaluated somewhere, even if not in that expression, so one still has help finding any problems that might exist in it.

[Mark-Simulacrum]

(Dropping nomination - I don't think this needs further lang discussion right now)

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[bors]

⌛ Testing commit f2ced78149c5cc44221492869dfae18bbaa51019 with merge 3e8060c917c39b726906aafca7f7b1341ff44866...

[rust-log-analyzer]

The job x86_64-gnu-llvm-9 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

💔 Test failed - checks-actions

[RalfJung]

Rebased... but then I realized this is a network problem:

Couldn't connect to server (Failed to connect to crates.io port 443: Network is unreachable)

@bors retry

[RalfJung]

@bors r=oli-obk

[bors]

📌 Commit 7f3e18c has been approved by oli-obk

[bors]

⌛ Testing commit 7f3e18c with merge 11c94a1...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 11c94a1 to master...