Rust 1.46
blog.rust-lang.org
Rust 1.46
1–10 of 157 posts
Re: Rust 1.46
#2The most exciting component of this release is the const fn improvements. With loops and if available, you can now do non-trivial computation in const fn for the first time. It reduces the gap between Rust's const fn and C++'s constexpr to a large degree. Ultimately, the miri execution engine that this feature builds upon, supports a much larger set of features that even constexpr supports. It's been a project spanning years to get it merged into the compiler, used for const fn evaluation, and stabilize it's features (this part is far from over).
In addition to the linked examples, I have some code of my own which is made simpler due to this feature: https://github.com/RustAudio/ogg/commit/b79d65dced32342a5f93...
Previously, the table was present as an array literal in C-style, now I can remove it once I decide for the library to require the 1.46 compiler or later versions.
Link to the old/current generation code: https://github.com/RustAudio/ogg/blob/master/examples/crc32-...
Re: Rust 1.46
#3If anyone wants to know more about const fns, see https://doc.rust-lang.org/reference/items/functions.html#con...
It is the Rust way of specifying a function as being _pure_. In other words the output is dependent only on the function arguments, and not on any external state.
This means they can be evaluated at compile time. I suppose in the future, it could also allow better compiler optimizations.
Re: Rust 1.46
#4These const fn’s are cool, but won’t this also lead to long compile times down the road?
Re: Rust 1.46
#5The quality of life improvements to cargo look very nice, and I feel that rust wouldn't be remotely as successful without such a tool. I'm very glad I won't have to be manually picking target directories out of my borg backups anymore when I'm running out of disk space.
Re: Rust 1.46
#6I’m learning rust right now and there is a lot to like. Steady updates like this are also very motivating. The ecosystem feels very sane - especially compared to npm. Top notch Wasm support, cross compiling is a breeze.
That said, coming from a FP background (mostly Haskell/JS, now TS) Rust is... hard. I do understand the basic rules of the borrow checker, I do conceptually understand lifetimes, but actually using them is tricky.
Especially in a combinator world with lots of higher order functions/closures it’s often completely unclear who should own what. It often feels my library/dsl code needs to make ownerships decisions that actually depend on the usage.
Anyways, I guess this gets easier over time, right? Should I avoid using closures all over the place? Should my code look more like C and less like Haskell?
[edit] great answers all, providing useful context, thanks
Re: Rust 1.46
#7If anyone wants to know more about const fns, see https://doc.rust-lang.org/reference/items/functions.html#con... It is the Rust way of specifying a function as being _pure_. In other words the output is dependent only on the function arguments, and not on any external state. This means they can be evaluated at compile time. I suppose in the future, it could also allow better compiler optimizations.
Never worked with Rust, but I am pretty sure that having a function be pure is not enough to evaluate it at compile time.
Re: Rust 1.46
#8Note that entire rust team was recently fired from Mozilla, so it is unclear how the future looks like for the language. Especially since it does not have a spec and only have single reference implementation
Re: Rust 1.46
#9These const fn’s are cool, but won’t this also lead to long compile times down the road?
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.
Re: Rust 1.46
#10These const fn’s are cool, but won’t this also lead to long compile times down the road?
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();
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