You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: vision/why-compile-time-evaluation.md
+6-3Lines changed: 6 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -6,9 +6,12 @@ This section is, in many ways, the most important. It aims to clarify the reason
6
6
7
7
People already precompute certain data structures, lookup tables, and so on, at compile time.
8
8
For example the crate `regex` could be able to compile a regex at compile time,
9
-
improving the performance when using `regex` and even removing the need for runtime allocations.
9
+
improving the performance when using `regex` and even removing the need for runtime allocations.
10
+
Const evaluation is also very useful to assert correctness requirements at compile time, instead
11
+
of using a runtime panic.
10
12
11
-
Without good const evaluation support, is often easier to just use a `build.rs` file for this or compute it externally and generate the result outside of the ordinary compilation process. If that isn't possible or sensible, one often just requires the computation to happen at runtime, negatively impacting startup performance.
13
+
Without good const evaluation support, is often easier to just use a `build.rs` file for this or compute it externally and generate the result outside of the ordinary compilation process. This is both worse for the user, as they essentially have to learn yet another
14
+
meta language, and also negatively impacts the compilation speed and incremental compilation. If that isn't possible or sensible, one often just requires the computation to happen at runtime, negatively impacting startup performance.
12
15
13
16
Computing things outside without using const eval makes it at lot more cumbersome to use and
14
17
prevents the input for that computation to simply be a generic or function parameter.
@@ -38,7 +41,7 @@ Reading or writing code which can be used at compile time should ideally not be
38
41
than writing other code. Requiring a lot of weird trait bounds or other hacks should be avoided as much as possible.
39
42
Supporting compile time evaluation should not worsen the experience of users, especially for beginners.
40
43
41
-
## Reliable: "if it passes `cargo check`, it works"
44
+
###Reliable: "if it passes `cargo check`, it works"
42
45
43
46
Const evaluation failures should be detected as early as possible, even when using `cargo check`. When writing library code, incorrect constants
44
47
should cause warnings and errors whenever possible.
0 commit comments