Nits and reading flow

Author: hackmd-deploy

posts/inside-rust/0000-00-00-const-eval-roadmap-and-skill-tree.md

@@ -5,13 +5,13 @@ author: Oli Scherer
 team: the const eval working group <https://github.com/rust-lang/const-eval/>
 ---
 
-Y'all probably noticed that const eval finally got loops, mutable local variables and branches. With those features existing, we were able to make a lot of basic arithmetic functions `const fn `. Things like `checked_div` needs to be able to check that the divisor is not zero and return `None` in that case. These features have been asked for a lot, and while it may not appear so, these were the low hanging fruit.
+Y'all probably noticed that const eval finally got loops, mutable local variables and branches. With those features stabilized, we were able to make a lot of basic arithmetic functions `const fn` on the stable compiler. These features have been asked for a lot, and while it may not appear so, these were the low hanging fruit.
 
 So you may now be thinking "If the low hanging fruit took you 5 years" *(yes oli-obk has been working on const eval for that long, and in the end ecstaticmorse implemented const control flow)*, "will we see any of the more fancy features in this new decade?".
 
 TLDR: Yes, and we now have a system for making things go ~~fast~~ brrr while still making sure we don't accidentally bypass the decision processes.
 
-Instead of creating more and more [RFCs](https://github.com/rust-lang/rfcs/) or [MCPs](https://github.com/rust-lang/lang-team/) and DDOSing the language team, we made one roadmap that doesn't contain the actual details of each feature. The plan is a tree-graph that lists the dependencies between features. The language team then signs off on the roadmap, giving the const-eval team the permission to experiment with unstable features without checking back with the language team. Stabilization of any of the features will still work by having a language team sign off, but that can then be done with the full knowledge about the final product instead of hypotheticals. If new features that are not yet on the plan are desired to get implemented, the roadmap is adjusted and the language team signs off on the roadmap changes.
+Instead of creating more and more [RFCs](https://github.com/rust-lang/rfcs/) or [MCPs](https://github.com/rust-lang/lang-team/) and DDOSing the language team, we made one roadmap that doesn't contain the actual details of each feature. The plan is a tree that lists the dependencies between features. The language team then signs off on the roadmap, giving the const-eval team the permission to experiment with unstable features without checking back with the language team. Stabilization of any of the features will still work by having a language team sign off, but that can then be done with the full knowledge about the final product instead of hypotheticals. If new features that are not yet on the plan are desired to get implemented, the roadmap is adjusted and the language team signs off on the roadmap changes.
 
 This new scheme makes it much easier to keep an overview over how features interact with other features. So without further ado (and hoping that the previous sentence's statement is true), let's introduce the