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

This commit is contained in:
Felix S. Klock II 2015-10-09 14:08:06 +02:00
parent b6a4f0393b
commit e1aba75a97

View File

@ -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