review comment: point out that the dropck analysis is now trivial.
This commit is contained in:
parent
b6a4f0393b
commit
e1aba75a97
@ -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
|
||||
|
Loading…
x
Reference in New Issue
Block a user