Oli Scherer

Ugh. Looks like we painted ourselves into a corner. Let's see if we can spiderman our way out. So... new rule. The final value of a constant/static may either be...

> Note that contrary to what I thought, rejecting types with Drop does not help as my hypothetical example with a drop-free leaking String shows. Yea I realized that from...

> `const E: &Vec = &vec![String::from("foo")]; // OK?` Hm... yea, I did not think about this properly. A raw pointer can just be `*const ()` but be used after casting...

Since we can call `foo` at runtime, too, allowing `S` in there will get us into the same problems that `bar` would get us into. > Does this run destructors?...

Ok, so basically C++ avoids the issues we've talked about here by using copy constructors whenever it moves to a non-constexpr space. This basically is ```rust const A: String =...

The problem occurs when you move to a `static` that contains interior mutability. So e.g. ```rust static S: Mutex = Mutex::new(C); *S.lock() = String::new(); ``` The old value is dropped...

As Ralf mentioned. Statically checking for transience is necessary for associated constants in trait declarations (assoc constants may not be evaluable immediately because they depend on other associated consts that...

So... @gnzlbg had a discussion on discord that I'm going to summarize here. The TLDR is that we believe a good solution is to have (names bikesheddable!) `ConstSafe` and `ConstRefSafe`...

```rust const MUTABLE_BEHIND_RAW: *mut i32 = &1 as *const _ as *mut _; ``` will also end up as mutable allocation (and compiles on stable). Is there any reason we...

> That's a regression, I'm pretty sure we used to make that immutable before miri. Probably. If we unify the promoted scheme between constants and functions that will be immutable...