On Fri, Mar 14, 2014 at 9:35 PM, Alex Crichton <a...@crichton.co> wrote:
> > 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.) > > Yes, by disallowing taking the address of non-Freeze non-mut > (confusing, right?) statics, we can allow non-Freeze values in non-mut > statics. > > > While I understand the motivation here, couldn't/shouldn't this use case > be > > served by an `init_atomic_uint!()` macro? > > Sadly not quite, the fields of an `AtomicUint` should be private, and > macros don't bypass privacy (they're just AST expansion) > Ah, but I think they should :). This is connected to hygiene: which says that identifiers in a macro body should always refer to entities in scope at the point of the macro's declaration, and not at its instantiation. The idea that privacy/visibility should be handled according to the same principle follows naturally. What hornet's nest would this stir up with respect to implementation?
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
