|
8 | 8 | > [_BlockExpression_]
|
9 | 9 | >
|
10 | 10 | > _FunctionFront_ :\
|
11 |
| -> `unsafe`<sup>?</sup> (`extern` _Abi_<sup>?</sup>)<sup>?</sup> |
| 11 | +> `const`<sup>?</sup> `unsafe`<sup>?</sup> (`extern` _Abi_<sup>?</sup>)<sup>?</sup> |
12 | 12 | >
|
13 | 13 | > _Abi_ :\
|
14 | 14 | > [STRING_LITERAL] | [RAW_STRING_LITERAL]
|
@@ -160,6 +160,38 @@ attributes], [`must_use`], [the procedural macro attributes], [the testing
|
160 | 160 | attributes], and [the optimization hint
|
161 | 161 | attributes].
|
162 | 162 |
|
| 163 | +## Const functions |
| 164 | + |
| 165 | +Functions can be `const`, meaning they can be called from within array length expressions and the initializer of constants, statics and enum discriminants. When called from such a so-called "const context", the function is interpreted by the compiler at compile time. The interpretation happens in the environment of the compilation target and not the host. So `usize` is `32` bits if you are compiling against a `32` bit system, irrelevant of whether you are building on a `64` bit or a `32` bit system. |
| 166 | + |
| 167 | +If a `const fn` is called outside a "const context", it is indistinguishable from any other function. You can freely do anything with a `const fn` that you can do with a regular fn. |
| 168 | + |
| 169 | +`const fn`s have various restrictions to makes sure that you cannot define a `const fn` that can't be evaluated at compile-time. You will, for example, never be able to write a random number generator as a const fn. Calling a const fn at compile-time will always yield the same result as calling it at runtime, even if you call it multiple times. There's one exception to this rule: if you are doing complex floating point operations in extreme situations, then you might get (very slightly) different results. It is adviseable to not make array lengths and enum discriminants depend on floating point computations. |
| 170 | + |
| 171 | +Exhaustive list of permitted structures in `const fn`: |
| 172 | + |
| 173 | +1. type parameters where the parameters have any of the following as part of their bounds (either on `where` or directly on the parameters): |
| 174 | + 1. lifetimes |
| 175 | + 2. `Sized` |
| 176 | + |
| 177 | + This means that `<T: 'a + ?Sized>` and `<T: 'b + Sized>` + `<T>` are all permitted. |
| 178 | + Note that `?Sized` is the absence of a constraint when bounds have been fully elaborated |
| 179 | + which includes adding implicit `Sized` bounds. |
| 180 | + This entails that permitting `Sized` + lifetimes allows the above examples. |
| 181 | + |
| 182 | + This rule also applies to type parameters of items that contain `const fn`s. |
| 183 | + |
| 184 | +2. arithmetic operators on integers |
| 185 | +3. boolean operators (except for `&&` and `||` which are banned since they are short-circuiting). |
| 186 | +4. any kind of aggregate constructor (array, `struct`, `enum`, tuple, ...) |
| 187 | +5. calls to other *safe* `const fn`s (methods and functions) |
| 188 | +6. index operations on arrays and slices |
| 189 | +7. field accesses on structs and tuples |
| 190 | +8. reading from constants (but not statics, not even taking a reference to a static) |
| 191 | +9. `&` and `*` (only dereferencing of references, not raw pointers) |
| 192 | +10. casts except for raw pointer to `usize` casts |
| 193 | +11. `const unsafe fn` is allowed, but the body must consist of safe operations only and you won't be able to call the `const unsafe fn` from within another `const fn` even if you use `unsafe` |
| 194 | + |
163 | 195 | [IDENTIFIER]: identifiers.html
|
164 | 196 | [RAW_STRING_LITERAL]: tokens.html#raw-string-literals
|
165 | 197 | [STRING_LITERAL]: tokens.html#string-literals
|
|
0 commit comments