|
|
@ -79,17 +79,5 @@ if condition {
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
As of Rust 1.0, the drop flags are actually not-so-secretly stashed in a hidden
|
|
|
|
The drop flags are tracked on the stack and no longer stashed in types that
|
|
|
|
field of any type that implements Drop. Rust sets the drop flag by overwriting
|
|
|
|
implement drop.
|
|
|
|
the entire value with a particular bit pattern. This is pretty obviously Not
|
|
|
|
|
|
|
|
The Fastest and causes a bunch of trouble with optimizing code. It's legacy from
|
|
|
|
|
|
|
|
a time when you could do much more complex conditional initialization.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
As such work is currently under way to move the flags out onto the stack frame
|
|
|
|
|
|
|
|
where they more reasonably belong. Unfortunately, this work will take some time
|
|
|
|
|
|
|
|
as it requires fairly substantial changes to the compiler.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Regardless, Rust programs don't need to worry about uninitialized values on
|
|
|
|
|
|
|
|
the stack for correctness. Although they might care for performance. Thankfully,
|
|
|
|
|
|
|
|
Rust makes it easy to take control here! Uninitialized values are there, and
|
|
|
|
|
|
|
|
you can work with them in Safe Rust, but you're never in danger.
|
|
|
|
|
|
|
|