Skip to content

Commit a4655ea

Browse files
fix: correct destruction order comments in Drop TempFile example (#1925)
The comments incorrectly stated that File's drop runs before the custom drop implementation. In Rust, the custom drop method runs first, and then fields are dropped afterwards. Updated comments to reflect the actual destruction order.
1 parent 8819d3e commit a4655ea

1 file changed

Lines changed: 7 additions & 3 deletions

File tree

src/trait/drop.md

Lines changed: 7 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -76,15 +76,19 @@ impl TempFile {
7676
}
7777
7878
// When TempFile is dropped:
79-
// 1. First, our drop implementation will remove the file's name from the filesystem.
80-
// 2. Then, File's drop will close the file, removing its underlying content from the disk.
79+
// 1. First, our custom drop implementation runs. The file is still open at this point,
80+
// but we can remove it from the filesystem by path.
81+
// 2. Then, after our drop returns, Rust automatically drops each field,
82+
// so File's drop runs and closes the file handle.
8183
impl Drop for TempFile {
8284
fn drop(&mut self) {
85+
// Note: the File is still open here — field destructors run after this method.
8386
if let Err(e) = std::fs::remove_file(&self.path) {
8487
eprintln!("Failed to remove temporary file: {}", e);
8588
}
8689
println!("> Dropped temporary file: {:?}", self.path);
87-
// File's drop is implicitly called here because it is a field of this struct.
90+
// After this method returns, Rust will drop each field (including `file`),
91+
// which closes the underlying file handle.
8892
}
8993
}
9094

0 commit comments

Comments
 (0)