(There didn't seem to be a zulip topic for this one so I figured we could open one. Mods please merge this if I missed it.)
It seems like a very obvious thing to have, and there's not much design to be done for this particular thing. The language allows mutable references in const or not, there's no syntax questions or anything like that. I think that the hold up, if any, would be in the const evaluator.
Has the past year of general const evaluation improvement made this something that could be pushed towards stable any time sooner than "no ETA"?
I was planning on retaking this in a few weeks but I have no idea when this will be suitable for stabilization.
I think there are still a few issues (e.g.
const FOO: &mut T, let me grab the topic.
Maybe we should split the feature gate into
&mut in args/variable types and
const types and return types
If we were to ban the creation of a mutable reference to a local at the "top-level", inside a const or static initializer, I think we can allow everything it inside
const fn. Inside a
const fn, the borrow checker does the "escape analysis" to ensure a mutable reference does not escape to the containing scope. However, at the top-level, everything is
&mut can escape from the initializer into the final value of a const.
As long as we are willing to settle for post monomorphization errors for programs with UB, we can also allow
*mut in the return type of a
I think I'll need a bit of mentoring for this
hmm... not 100% sure, but isn't this essentially equivalent to the existing interior mutability checks?
&&mut T is technically ok
I'd be fine with being overconservative for now and forbidding
&&mut T right now
So we could just extend https://github.com/rust-lang/rust/blob/ecde10fc283530db0db42e2c3e2e3132e809b139/src/librustc_mir/transform/check_consts/qualifs.rs#L196 to also cover mutable references