> Can someone explain why this is necessary? > > static FOO: Option<Cell<int>> = None; > let foo = &FOO;
Implementation-wise, FOO is placed into read-only memory in the executable. This is done mainly for optimization purposes for LLVM. Something like static NUM_BITS: uint = 32; should act like a #define in C, so we must mark it as constant (read-only) > Why would this be a problem? Or is this not what's being referred to? If you attempt to mutate read-only memory, you get a signal. See https://github.com/mozilla/rust/issues/10577 for more info > Actually... given that you can't move out of a static, and all > functions/methods are either by value (moves) or by ref (takes address), > this means the only way you could interact with a non-Freeze static _at all_ > is if it were Pod/Copy. But Pod/Copy types are never non-Freeze. That's close, but there's on other crucial use case, which is initialization of other statics. Consider atomics static INIT_ATOMIC_UINT: AtomicUint = ...; static mut CNT: AtomicUint = INIT_ATOMIC_UINT; The first static should *not* have to be mut, because then you can mutate the initial pattern, which seems weird. Hence, we forbid taking the address of INIT_ATOMIC_UINT. The second one, however, must be mutable, but it's also in a module outside of where AtomicUint is defined. We use the original bit-pattern, copying it into read-write memory so we can modify it. We allow taking the address of `static mut` memory. In general though, yes, a non-freeze static is only useful as a *value* if it's Copy, but it's quite useful for other static initialization. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev