Inside Rust: const eval roadmap

[oli-obk]

I'm writing this in https://hackmd.io/7Rs5q0h4TImeOGbv9NYxcQ

This is the blog post discussed in the language team meeting at https://github.com/nikomatsakis/lang-team/blob/master/design-meeting-minutes/2020-06-24-const-eval-unsafe-and-skill-tree.md

cc @rust-lang/wg-const-eval @joshtriplett

[wesleywiser]

Exciting! 🎉

[RalfJung]

I don't understand the purpose of the 2nd sentence here ("Things like..."). It seems unrelated to the first and third sentence, and just cutting it doesn't leave a gap as far as I can see.

[oli-obk]

I didn't know where to put an example... Maybe I could just say

basic arithmetic functions (e.g. checked_div) const fn

?

[RalfJung]

Yes, that seems much better. Also checked_div seems rather niche, isn't there something "bigger"?

[jyn514]

I think unwrap_or works now and didn't before, anything with Option or Result really.

[oli-obk]

I chose checked_div because it's pretty obvious what it does. the Option/Result methods may still have some blockers somewhere, not sure if we fixed/stabilized the drop fixes needed for that.

[RalfJung]

What about "(e.g. checked and saturating arithmetic)"? That makes it less specific to "div".
(I am looking at https://blog.rust-lang.org/2020/08/27/Rust-1.46.0.html to see what got stabilized there.)

[RalfJung]

One question about the skill tree itself: So far, I think we removed (or planned to remove) nodes when they got stabilized. Would it make more sense to instead change their color or so? That would (a) keep the useful dependency information around, and (b) give a nice sense of progress as the entire graph slowly changes color. :D

[oli-obk]

That would (a) keep the useful dependency information around, and

Is it still useful? There's no dependency anymore. It's more historical information. Maybe I could extend the skill tree generator to output two graphs? One with all nodes (and outdated ones grayed out or something) and one with just the still active nodes.

(b) give a nice sense of progress as the entire graph slowly changes color. :D

I like progress being the graph having less parts ^^ Like the entire graph is just the things we still have to work at without keeping parts in it that are done.

[RalfJung]

I like progress being the graph having less parts ^^ Like the entire graph is just the things we still have to work at without keeping parts in it that are done.

I expect more nodes will be added as we discover more things we want to do during CTFE. So we might make progress without the graph getting smaller. Or is that not how you intended this to go?

[oli-obk]

So we might make progress without the graph getting smaller. Or is that not how you intended this to go?

No, that is indeed how I intended this to work.

If we keep around old nodes the graph will grow indefinitely, even if it contains things that have been stable for a long time and some ppl on the project may not even know that this didn't work some time in the past. If we remove things (maybe after a grace period), the graph will only be the (future?) roadmap, and not a general overview over the past and future features of const eval.

What do you think about going with both our preferred systems and just making two graphs out of the same skill tree file?

[RalfJung]

If you don't think keeping the old nodes around is useful, I am okay with dropping them. We have the git history for historic information. I just felt like it could be an interesting thing to present, but I might just be wrong about it being interesting. ;)

[rylev]

@oli-obk I'm guessing this has gone pretty stale. Shall we close this?

[oli-obk]

Yea, I guess