The current state of compile-time evaluations in rust

Constants can be declared with the const keyword.

Usually you want to declare constants in the module namespace (i.e. outside main). They will be immutable unlike static values.

Of course, this features constant propagation meaning that expressions like 2 * 3 are evaluated at compile time and only the resulting value will be assigned.

Allocations on the heap are not allowed to create a constant value. Be aware that Vec, Box, … are always allocated on the heap. Thus for example, a vector Vec cannot be declared const.

If you can mutate a collection, it is obviously not constant.

But is the distinction between mutable and immutale not given by the mut keyword? It is. To the best of by knowledge, any constant collection is immutable. But is every immutable collection constant? I think there might be compiler constraints making this statement false.

So we need an immutable data structure without allocations. The simplest type is an array. An array can be made const.

Regarding pointers in unsafe rust, you need to be aware that *const T is covariant whereas *mut T is invariant.

Obviously, any individual element of the array by assignment.

Its length; the number of elements.

Its initializer; all elements take the value of the initializer.

const generics became stable recently. Thus, we can be generic over the length of an array:

struct PubKey<const LEN: usize> {
    data: [u8; LEN],
}

fn main() {
    println!("{:?}", PubKey{ data: [42u8, 1, 6, 52] }.data);
}

“Shipping Const Generics in 2020” by Withoutboats, who initiated const generics in RFC 2000. The article discusses more technical details about const generics.

One limitation is const_evaluatable_checked. You cannot be generic over the length of an array depending on several generic const values. A thread on users.rust-lang.org discusses the issue and points to the generic-array crate.

rust 1.31 (Dec 2018) introduced const fn.

const fn has been extended for if-conditionals, match, and other features consecutively.

For example, you can compute the array, you want to assign to a constant value:

const fn fill() -> [u8; 42] {
    let mut x = [0u8; 42];
    x[1] = 42;
    return x;
}

const ARR: [u8; 42] = fill();

fn main() {
    println!("{}", ARR[1]);
}

However, not all computations are possible. for loops are not allowed. Compare with the nightly documentation or edition guide’s “The next edition” section.

For boolean values:

For non-bool values:

Build scripts is a universal answer. Placing a file named build.rs in the root of a package will cause Cargo to compile that script and execute it just before building the package.

We restricted our discussion to compilation time evaluation. So the goal is to get a const value in the rust code.

Here const-generic and const-fn come in handy. They are young features with limitations.

Before these features, rust was much less powerful than C. I had to duplicate an entire file for my NewHope implementation and edit array sizes manually.

I think templates and constexpr in C++ are a mess. I always hoped for a file which evaluates a compile time and evaluates all compile time values. Then these values can be used at run time as constants. rust’s build scripts come really close to this concept.

If you are happy with boolean values, you can use attributes (allowlisted keys) and features (arbitrary keys). They have a nice feature set.

If you want to pass arbitrary strings, you can use environment variables (fetch values with env!) (const fn is only useful for simple computations) or build scripts (arbitrary computation).

But if you need other types or need pre-processing, then you can write rust files into the package dynamically with build scripts. This is an error-prone approach.