[cordite]

These const fn’s are cool, but won’t this also lead to long compile times down the road?

[steveklabnik]

Yes, any time you move computation to compile time, it makes the compile time take longer. As always it is a tradeoff.

One thing that people may not realize, especially now that we have loop. You may expect this to hang the compiler:

    const fn forever() -> ! {
        loop {
            
        } 
    }
    
    static FOO: u32 = forever();

But it won't:

    error[E0080]: could not evaluate static initializer
     --> src/lib.rs:2:5
      |
    2 | /     loop {
    3 | |         
    4 | |     } 
      | |     ^
      | |     |
      | |_____exceeded interpreter step limit (see `#[const_eval_limit]`)
      |       inside `forever` at src/lib.rs:2:5

This does place an upper limit on any given const fn.

[cordite]

That's fantastic!

That could be a real hard-to-source build stall.

[brundolf]

Nifty!

[Verdex]

Yeah, but only if you use them to compute significant items during compilation.

The upside of course is that any computation you compute at compile time is a computation that you don't compute at runtime. For some applications this trade off is definitely worth the cost of admission.

At the end of the day it's a trade off that will have to be made in light of the scenario it's being used in. Being able to make that decision is a good thing.