|
|
|
|
|
|
by dathinab
545 days ago
|
|
|
yes drop can't be responsible for safety in Vec::drain() by setting the Vec len to 0, std semantically moves all elements from the Vec to the Drain and in in Drain::drop it semantically moves the non drained elements back i.e. vec::Drain::drop is responsible for not leaking non drained elements, not for safety and sure not leaking means positioning them so in the vec that the len can be set to a value where all elements from 0..len have not been moved out etc. but that doesn't change that semantically it's responsibility is "not leaking" instead "making sure it's sound". |
|
|
- initially it was believed you can rely Drop for soundness
- then the rust community realized that this is an oversight -- the so called leakocalipyse
- there also was no easy straight forward way to fix that, in the end it was decided that leaking must be sound and `std::mem::forget` was added
- while there was some initial fallout (e.g. scoped threads and some &mut iterators now leaking collections if leaked) it wasn't to bad as you still can use function scopes to enforce some non leaking (i.e. if you accept a closure you can make sure something runs both before and after it)
- but with async functions a lot of the workarounds don't work anymore as the async function could be leaked mid execution by calling async functions ... so by now some people which rust had taken a different turn back then. But then to be fair this is the kind of "hypothetically wishing" because making leak sound was with the knowledge and constraints available back then very clearly the right choice.