Tracking issue for `&mut T` in const fn

[ExpHP]

This could be considered a subissue of #24111, however it does not (yet) correspond to a feature in the original RFC, nor does it necessarily correspond to anything that is implemented. It is simply that @Centril suggested I make an issue.

---

Basically, because &mut references are unique in rust, mutations (except through interior mutability) are not actually observable. Therefore, in theory, it would seem that const fn could support mutation. i.e.:

• &mut arguments could be accepted
• locals could be mutably borrowed (&mut expressions)
• non-initialization assignments could be made (x = y; or *x = y;).

I could not locate any real discussion on this to date.

Presently, we need to discuss whether we want to do this, and if so, what the scope is.

[Centril]

Thanks for filing this issue. :)

• non-initialization assignments could be made (x = y; or *x = y;).

The first half of this, i.e. x = y, is covered by #48821 which is being stabilized in #57175.

[alercah]

I could be wrong, but based on previous conversation with @eddyb, this is very much in the plans. They originally wanted to even allow CTFE to mutate statics during the scope of their execution, until it was discussed out that this is undesirable because it would allow a single function call to behave differently depending on whether or not CTFE was used to precompute the function.

[eddyb]

Please cc @oli-obk and/or @RalfJung on all CTFE-related things.

In terms of the implementation, we plan to allow all pointers where the memory they point to is on the CTFE "stack" (i.e. not a static) and maybe "heap" in the future, with maybe some limitations around const fn itself.

But miri can already interpret more than everything you'd reasonably want to run in CTFE.