review comment: point out that the dropck analysis is now trivial.

src/doc/nomicon/dropck.md

@@ -186,11 +186,13 @@ strictly outlive that value.
 The precise rules that govern drop checking may be less restrictive in
 the future.
 
-The current analysis is deliberately conservative; forcing all
-borrowed data in a value to outlive that value is certainly sound.
+The current analysis is deliberately conservative and trivial; it forces all
+borrowed data in a value to outlive that value, which is certainly sound.
 
-Future versions of the language may improve its precision (i.e. to
-reduce the number of cases where sound code is rejected as unsafe).
+Future versions of the language may make the analysis more precise, to
+reduce the number of cases where sound code is rejected as unsafe.
+This would help address cases such as the two Inspectors above that
+know not to inspect during destruction.
 
 In the meantime, there is an unstable attribute that one can use to
 assert (unsafely) that a generic type's destructor is *guaranteed* to