5
5
>   ;  ; ` static ` ` mut ` <sup >?</sup > [ IDENTIFIER] ` : ` [ _ Type_ ]
6
6
> ` = ` [ _ Expression_ ] ` ; `
7
7
8
- A * static item* is similar to a * constant* , except that it represents a precise
8
+ A * static item* is similar to a [ constant] , except that it represents a precise
9
9
memory location in the program. A static is never "inlined" at the usage site,
10
10
and all references to it refer to the same memory location. Static items have
11
11
the ` static ` lifetime, which outlives all other lifetimes in a Rust program.
12
- Static items may be placed in read-only memory if they do not contain any
13
- interior mutability .
12
+ Static items may be placed in read-only memory if the type is not [ interior
13
+ mutable ] . Static items do not call ` drop ` at the end of the program .
14
14
15
- Statics may contain interior mutability through the ` UnsafeCell ` language item.
16
15
All access to a static is safe, but there are a number of restrictions on
17
16
statics:
18
17
19
- * Statics may not contain any destructors.
20
- * The types of static values must ascribe to ` Sync ` to allow thread-safe
21
- access.
18
+ * The type must have the ` Sync ` trait bound to allow thread-safe access.
22
19
* Statics allow using paths to statics in the
23
20
[ constant-expression] ( expressions.html#constant-expressions ) used to
24
- initialize them, but statics may not refer to other statics by value, only by
25
- reference.
21
+ initialize them, but statics may not refer to other statics by value, only
22
+ through a reference.
26
23
* Constants cannot refer to statics.
27
24
28
- Constants should in general be preferred over statics, unless large amounts of
29
- data are being stored, or single-address and mutability properties are
30
- required.
31
-
32
25
## Mutable statics
33
26
34
27
If a static item is declared with the ` mut ` keyword, then it is allowed to be
@@ -64,7 +57,7 @@ unsafe fn bump_levels_unsafe2() -> u32 {
64
57
```
65
58
66
59
Mutable statics have the same restrictions as normal statics, except that the
67
- type of the value is not required to ascribe to ` Sync ` .
60
+ type does not have to implement the ` Sync ` trait .
68
61
69
62
## ` 'static ` lifetime elision
70
63
@@ -97,8 +90,6 @@ the standard elision rules ([see discussion in the nomicon][elision-nomicon]).
97
90
If it is unable to resolve the lifetimes by its usual rules, it will default to
98
91
using the ` 'static ` lifetime. By way of example:
99
92
100
- [ elision-nomicon ] : ../nomicon/lifetime-elision.html
101
-
102
93
``` rust,ignore
103
94
// Resolved as `fn<'a>(&'a str) -> &'a str`.
104
95
const RESOLVED_SINGLE: fn(&str) -> &str = ..
@@ -112,6 +103,19 @@ const RESOLVED_MULTIPLE: Fn(&Foo, &Bar, &Baz) -> usize = ..
112
103
const RESOLVED_STATIC: Fn(&Foo, &Bar) -> &Baz = ..
113
104
```
114
105
106
+ ## Using Statics or Consts
107
+
108
+ In can be confusing whether or not you should use a constant item or a static
109
+ item. Constants should, in general, be preferred over statics unless one of the
110
+ following are true:
111
+
112
+ * Large amounts of data are being stored
113
+ * The single-address or non-inlining property of statics is required.
114
+ * Interior mutability is required.
115
+
116
+ [ constant ] : items/constant-items.html
117
+ [ interior mutable ] : interior_mutability.html
115
118
[ IDENTIFIER ] : identifiers.html
116
119
[ _Type_ ] : types.html
117
120
[ _Expression_ ] : expressions.html
121
+ [ elision-nomicon ] : ../nomicon/lifetime-elision.html
0 commit comments