On Fri, Mar 14, 2014 at 8:32 PM, Alex Crichton <a...@crichton.co> wrote:
> > 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 > (I was already aware of the context up to this point.) I was working from the assumption that the initializers of non-mut statics are checked to ensure they do not contain values of non-Freeze types, nor destructors. Does the new plan also involve lifting this restriction? (From the below it seems like it does.) > > > 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. > Ah, this is the piece I was missing: that statics may be used to initialize other statics (which doesn't involve moving). While I understand the motivation here, couldn't/shouldn't this use case be served by an `init_atomic_uint!()` macro?
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
