In many cases the functions being constified were already evaluated during compilation where possible though, the compile time cost was already sunk.

Making them const just formally guarantees the compiler can evaluate them at compile time which makes them useful in more contexts.

"constexpr of all things" kind of proves the point in compile times, and so far Rust isn't fairing much better in that regard.

I think the point is that rustc + llvm has long made everything "constexpr" (well as much as it can). After all it's a missed optimization if it fails to evaluate something at compile time if it can be so evaluated.

`const fn` is merely an API guarantee that the function can always be evaluated at compile time if the arguments are themselves known at compile time.

Not a rust user. Could const be inferred instead of needing to be explicit? At least, hypothetically?

In theory, yes. In practice, it is an API commitment, and so it is not inferred, because you as a library author have to decide if you want to commit to it or not.

Maybe for stuff that never can be externally accessed, const should be inferred as an optimization pass.

Yes, this is already done. But that's not the more interesting part of the feature. Once you require something to be const, you can use it in contexts that require something to be const. Inferring it in non-const contexts is less powerful.

Long compile times suck but long runtimes suck more.

Counterpoint:

> When you have a small team that write tests and a compiler that is on the boundary of interactive speed, compiler speed dominates performance.

https://crawshaw.io/blog/fast-compilers

Rust is already not near the boundary of interactive speed.

Yes.

Can't the Rust compiler cache the evaluated outputs?

In theory yes, with the current LLVM toolchain doesn't look like it.

LLVM has nothing to do with `const` evaluation in Rust. `const` evaluation happens at the MIR level which participates in incremental compilation.

> cache the evaluated outputs

Was the point of my answer.

Apologies but as your comment currently stands, it reads to me like "in theory yes, but actually no".