Hacker News Reader

Comment by adamch | Hacker News Reader

It's a little thing, but one of my favourite parts of any Rust release is seeing which stdlib functions become `const`. The ergonomics of build-time evaluation are slowly improving, and I'm very excited to slowly do less at runtime!

View on HN

Can increase in use of `const fn`'s create a noticeable decrease in compile times? As someone whose never worked on compilers, I'm not really sure what the magnitude of that processing time is in relation to everything else.

The compiler would already evaluate most of this stuff at compile time, you just weren't allowed to rely on it until now.

e.g. char::is_ascii_alphabetic() was made const in 1.47, but 1.46 would already run it at compile time: https://godbolt.org/z/hWf65f

The difference is in 1.47 you can use the result to assign something that must be known at compile time.

The problem with "const of all things" is that you will get enough free time to prepare a big meal.

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.

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

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.

What does "becoming const" mean?

Means that functions are evaluated at compile time.

However in this case, these are const generics, so you no longer need to use macro to generate [char;1],[char;2]...

You just write [char; N] where N is const. Compiler determines which values of N are used and generates for them an appropriate version.

can be, you can call them at runtime too. And to be clear, const generics aren't stable yet, they're being used as an implementation detail of the standard library here, you cannot yet use them on stable in your code.

> However in this case, these are const generics, so you no longer need to use macro to generate [char;1],[char;2]...

Const generics still aren't stable. I believe the GP was talking about the list of new `const fn`s in the release (near the bottom of the post).

I believe it's similar to "constexpr" in C++ -- it means those functions can now be evaluated at compile time.

https://doc.rust-lang.org/reference/items/functions.html#con...

Basically, const functions can be used in places regular functions can't because they are directly "run" by the compiler at compile time.

Const values are inlined at compile time wherever they are used.

Const functions let you run code to define const values. This code will be run at compile time before the const values are inlined.

For example let's say you have a constant for PI but you need 2*PI. You could do the multiplication in const context, meaning the multiplication will happen during compilation and not execution. Slowly more and more of the language is becoming usable in const context so more advanced things can be done during compile time.

Well, if you need `2*PI`, there’s now `f32::TAU` and `f64::TAU` :) You’re still correct though

I like that const functions occupy a space between a normal function and hygienic macros. You can avoid writing out lookup tables long-form where the entries are very predictable. For instance you could write a base64 encoder and decoder without putting ["a", "b", "c"... ] in your code base, and then have to worry if you accidentally put "D" in there twice. The typical alternative in other languages is to evaluate this at startup time, which adds latency to your program.

Compile-time function evaluation is also one of the features of the Jai programming language. If you can't get people to use your language, getting them to steal all your features is a good consolation prize.

> If you can't get people to use your language, getting them to steal all your features is a good consolation prize.

It's difficult to use Jai as long as it only exists on Jonathan Blows computer, he still hasn't released it

Reply on news.ycombinator.com