Rust's system for globals / constants is not ideal

[thestinger]

It has pointless restrictions that are forever going to hurt code generation and expressiveness like const being an rvalue and static having a significant address. There were better ways of accomplishing the goal of allowing internal mutability in static and initialization of types with internal mutability with const without it being broken. The only restriction really needed for const was forbidden the definition of external ones. Whether or not the underlying variable is marked as constant in LLVM is an implementation detail. Taking an address of a const containing UnsafeCell could have been forbidden but it is not strictly necessary - const could allow internal mutability just like const variables in C++.

[arielb1]

Being able to take the address of a const would be crazy – that's what static is for (through we need to add address-insignificant static).

[thestinger]

I don't see how it's crazy. You're using circular reasoning to justify the distinction. Treating constants as rvalues is bloated and inefficient. There is no justification for not permitting the address to be taken for types without internal mutability. It's a job for the borrow checker, not a hack involving duplication of the value as an expression everywhere.

[thestinger]

All globals should have insignificant addresses whether they have inherited mutability, internal mutability or are truly constant. It opens up many opportunities for reducing code size / improving performance via merging - sometimes after proving that a mutable global is only read from. There isn't a valid use case for significant addresses because the same thing can be accomplished with types / type ids and zero-size types never have a meaningful address anyway.

[glaebhoerl]

Might make sense to clearly separate the semantics from the implementation. consts could be semantically rvalues, and the lifetime of any reference to them could be enclosing stack frame, but as an optimization, the compiler could store a single global instance instead of one per stack frame. (Or it could not - the point is that the semantics don't preclude it, at least when interior mutability isn't involved.)

[thestinger]

If they're semantically an rvalue, then you can't get an &'static reference so it's not a viable replacement for static. I don't know why it isn't just a borrow checking restriction when there's internal mutability. The high-level semantics might as well be powerful and match up 1:1 to an efficient implementation with no duplication. The definitions can be inlined across crates using available_externally so there will never be duplicated instances across crate boundaries.

[arielb1]

Of course, non-zero-sized internal mutability ensures some kind of address significance. consts really shouldn't have a significant address (so constants that contain an UnsafeCell must be rvalues), but on the other hand, allowing &'static borrows of constants without internal mutability seems to be fine.

[thestinger]

In some cases, a mutable global will only be read from so LLVM can convert it to a constant. It can then merge these globals together if they are marked unnamed_addr. It has no impact if it can't prove that it wouldn't change behaviour, but I don't see a reason to leave it off.

[nikomatsakis]

Closing in favor of #1056, which describes a specific, backwards compatible change that would (I believe) achieve the aims described here.