Skip to content

Commit 68bcc95

Browse files
committed
update docs
1 parent b6e0669 commit 68bcc95

File tree

1 file changed

+6
-3
lines changed

1 file changed

+6
-3
lines changed

vision/why-compile-time-evaluation.md

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -6,9 +6,12 @@ This section is, in many ways, the most important. It aims to clarify the reason
66

77
People already precompute certain data structures, lookup tables, and so on, at compile time.
88
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.
1012

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.
1215

1316
Computing things outside without using const eval makes it at lot more cumbersome to use and
1417
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
3841
than writing other code. Requiring a lot of weird trait bounds or other hacks should be avoided as much as possible.
3942
Supporting compile time evaluation should not worsen the experience of users, especially for beginners.
4043

41-
## Reliable: "if it passes `cargo check`, it works"
44+
### Reliable: "if it passes `cargo check`, it works"
4245

4346
Const evaluation failures should be detected as early as possible, even when using `cargo check`. When writing library code, incorrect constants
4447
should cause warnings and errors whenever possible.

0 commit comments

Comments
 (0)