self review

0000-template.md

@@ -6,7 +6,7 @@
 # Summary
 [summary]: #summary
 
-Cleanup the rules for implicit drops by splitting `#[may_dangle]` into two separate attributes
+Cleanup the rules for implicit drops by splitting `#[may_dangle]` into two separate attributes:
 `#[only_dropped]` and `#[fully_ignored]`. Change `PhantomData` to get completely ignored
 by dropck as its current behavior is confusing and inconsistent.
 
@@ -79,7 +79,7 @@ fn can_drop_dead_reference() {
 }
 ```
 The above example will however fail if we add a manual `Drop` impl as the compiler conservatively
-assumes that all generic parameters of the `Drop` impl are considered used:
+assumes that all generic parameters of the `Drop` impl are used:
 [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e604bcaecb7b2b4cf7fd0440faf165ac).
 
 In case a manual `Drop` impl does not access a generic parameter, you can add
@@ -116,8 +116,8 @@ fn can_drop_dead_reference() {
 }
 ```
 
-The ability to differentiate between `#[fully_unused]` and `#[only_dropped]` is especially useful
-for type parameters, consider the following simplified types from the standard library:
+The ability to differentiate between `#[fully_unused]` and `#[only_dropped]` is significant
+for type parameters:
 
 ```rust
 pub struct BTreeMap<K, V> {
@@ -155,13 +155,12 @@ When implicitly dropping a variable of type `T`, liveness requirements are compu
     - or they are marked with `#[only_dropped]`, in which case recurse into the generic argument.
 - Regardless of whether `T` implements `Drop`, recurse into all types *owned* by `T`:
     - references, raw pointers, function pointers, function items and scalars do not own
-      anything. They are trivially drop.
+      anything. They can be trivially dropped.
     - tuples and arrays consider their element types to be owned.
     - all fields (of all variants) of ADTs are considered owned. We consider all variants
-      for enums. The only exception here is `ManuallyDrop<U>` which does not consider `U` to
-      be owned. `PhantomData<U>` does not have any fields and therefore also does not consider
-      `U` to be owned. 
-    - closures and generators consider their upvars to be owned.
+      for enums. The only exception here is `ManuallyDrop<U>` which is not considered to own `U`. `PhantomData<U>` does not have any fields and therefore also does not consider
+      `U` to be owned.
+    - closures and generators own their captured upvars.
 
 Checking drop impls may error for generic parameters which are known to be incorrectly marked:
 - `#[fully_unused]` parameters which are recursively owned
@@ -178,8 +177,8 @@ into types owned by `T` to figure out the correct constraints.
 
 `PhantomData<U>` currently considers `U` to be owned while not having drop glue itself. This means
 that `(PhantomData<PrintOnDrop<'s>>, String)` requires `'s` to be live while
-`(PhantomData<PrintOnDrop<'s>>, u32)` does not. The current behavior is required for get the
-behavior of `#[only_dropped]` for unowned parameters by adding `PhantomData` as a field.
+`(PhantomData<PrintOnDrop<'s>>, u32)` does not. This is required for get the
+behavior of `#[only_dropped]` for parameters otherwise not owned by adding `PhantomData` as a field.
 One can easily forget this, which caused the [unsound](https://github.com/rust-lang/rust/issues/76367)
 [issues](https://github.com/rust-lang/rust/issues/99408) mentioned above.
 
@@ -204,9 +203,9 @@ It is therefore quite important to improve the status quo.
 
 A more general extension to deal with partially invalid types is far from trivial. We currently
 assume types to always be well-formed and any approach which generalizes `#[may_dangle]` will
-have huge consequences for how well-formedness is handled. This impacts many - often implicit -
+have major consequences for how well-formedness is handled. This impacts many - often implicit -
 interactions and assumptions. It is highly unlikely that we will have the capacity for any such change
-in the near future. The benefits from such are change are also likely to be fairly limited while
+in the near future. The benefits from such are change are likely to be fairly limited while
 adding significant complexity.
 
 # Prior art