Skip to content

Commit 06655aa

Browse files
committed
Merge remote-tracking branch 'alexcrichton/amend-static-vs-const'
2 parents 2e783d8 + 14bd7da commit 06655aa

File tree

1 file changed

+38
-0
lines changed

1 file changed

+38
-0
lines changed

text/0246-const-vs-static.md

+38
Original file line numberDiff line numberDiff line change
@@ -139,6 +139,8 @@ They may not be placed in read-only memory.
139139

140140
## Globals referencing Globals
141141

142+
### const => const
143+
142144
It is possible to create a `const` or a `static` which references another
143145
`const` or another `static` by its address. For example:
144146

@@ -163,10 +165,41 @@ will disallow `SomeStruct` from containing an `UnsafeCell` (interior
163165
mutability). In general a constant A cannot reference the address of another
164166
constant B if B contains an `UnsafeCell` in its interior.
165167

168+
### const => static
169+
170+
It is illegal for a constant to refer to another static. A constant represents a
171+
*constant* value while a static represents a memory location, and this sort of
172+
reference is difficult to reconcile in light of their definitions.
173+
174+
### static => const
175+
166176
If a `static` references the address of a `const`, then a similar rewriting
167177
happens, but there is no interior mutability restriction (only a `Sync`
168178
restriction).
169179

180+
### static => static
181+
182+
It is illegal for a `static` to reference another `static` by value. It is
183+
required that all references be borrowed. Additionally, not all kinds of borrows
184+
are allowed, only explicitly taking the address of another static is allowed.
185+
For example, interior borrows of fields and elements or accessing elements of an
186+
array are both disallowed.
187+
188+
If a by-value reference were allowed, then this sort of reference would require
189+
that the static being referenced fall into one of two categories:
190+
191+
1. It's an initializer pattern. This is the purpose of `const`, however.
192+
2. The values are kept in sync. This is currently technically infeasible.
193+
194+
Instead of falling into one of these two categories, the compiler will instead
195+
disallow any references to statics by value (from other statics).
196+
197+
## Patterns
198+
199+
Today, a `static` is allowed to be used in pattern matching. With the
200+
introduction of `const`, however, a `static` will be forbidden from appearing
201+
in a pattern match, and instead only a `const` can appear.
202+
170203
# Drawbacks
171204

172205
This RFC introduces two keywords for global data. Global data is kind
@@ -195,5 +228,10 @@ being, and create `const` declarations after Rust 1.0 is released.
195228
- Should we permit `static` variables whose type is not `Sync`, but
196229
simply make access to them unsafe?
197230

231+
- Should we permit `static` variables whose type is not `Sync`, but whose
232+
initializer value does not actually contain interior mutability? For example,
233+
a `static` of `Option<UnsafeCell<uint>>` with the initializer of `None` is in
234+
theory safe.
235+
198236
- How hard are the envisioned extensions to implement? If easy, they
199237
would be nice to have. If hard, they can wait.

0 commit comments

Comments
 (0)