> 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

Reply via email to