review

Author: lcnr

posts/inside-rust/2023-07-11-trait-system-refactor-initiative.md

@@ -7,7 +7,7 @@ team: The Rustc Trait System Refactor Initiative <https://github.com/rust-lang/t
 
 As announced in the [Types Team announcement post](https://blog.rust-lang.org/2023/01/20/types-announcement.html) at the start of this year, the Types Team has started to reimplement the trait solver of rustc. This refactor is similar to [chalk](https://github.com/rust-lang/chalk/), but directly integrated into the existing codebase using the experience gathered over the last few years. Unlike chalk, the new trait solver has the sole goal of replacing the exisiting implementation. We are separately working on formalizing the type system in [a-mir-formality](https://github.com/rust-lang/a-mir-formality).
 
-By reimplementing the trait solver of rustc we are able to fix many subtle bugs and inefficiencies of the existing implementation. This should result in faster compilation speed and bugs. The new trait solver implementation should also unblock many future changes, most notably around implied bounds and coinduction. This will allow us to remove many of the [current restrictions on GATs](https://github.com/rust-lang/rust/issues/91693) and to fix many long-standing unsound issues, for example [#25860](https://github.com/rust-lang/rust/issues/25860). Some unsound issues will already be fixed at the point of stabilization while others will require additional work afterwards. The new solver will also enable or greatly simplify other, still experimental type system extensions, e.g. [generic const expressions](https://github.com/rust-lang/rust/issues/76560) and [non-lifetime binders](https://github.com/rust-lang/rust/issues/108185).
+By reimplementing the trait solver of rustc we are able to fix many subtle bugs and inefficiencies of the existing implementation. This should result in faster compilation speed and fewer bugs. The new trait solver implementation should also unblock many future changes, most notably around implied bounds and coinduction. This will allow us to remove many of the [current restrictions on GATs](https://github.com/rust-lang/rust/issues/91693) and to fix many long-standing unsound issues, for example [#25860](https://github.com/rust-lang/rust/issues/25860). Some unsound issues will already be fixed at the point of stabilization while others will require additional work afterwards. The new solver will also enable or greatly simplify other, still experimental type system extensions, e.g. [generic const expressions](https://github.com/rust-lang/rust/issues/76560) and [non-lifetime binders](https://github.com/rust-lang/rust/issues/108185).
 
 It has now been half a year since that announcement which matches the first step of [our roadmap][roadmap].
 
@@ -23,7 +23,7 @@ While there is a significant tail of less common bugs, we currently have two mai
 
 After fixing the currently open issues, we intend to move parts of rustc to the new trait solver implementation in steps, starting by using it in coherence. We expect to move coherence to the new implementation at the end of this year. Moving the type checking of functions to the new trait solver implementation will be a lot more challenging than coherence. This will be the last place where we will use the old implementation. We expect to change the default there in 2024, potentially relying on the new edition to help with migration.
 
-A major challenge will be "incompleteness". The trait system sometimes unnecessarily guides type inference. Consider the following example:
+A major challenge will be "incompleteness". We use incompleteness as a technical term used whenever the type system unnecessarily guides type inference. Incompleteness allows code to compile which would otherwise be ambiguous, but it also makes the trait system order dependent and can result in incorrect and weird errors. Consider the following example:
 ```rust
 fn impl_trait() -> impl Into<u32> {
     0u16