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".

some random additional information:

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

One nitpick, `std::mem::forget` already existed it was just marked as unsafe before.

That would make the lifetime last forever, preventing you from ever getting the mutable reference back and causing any safety issues. (Your intuition serves you well, though: graphics APIs designed to commit on a guard type's Drop::drop are prone to panicking, since the GPU driver does not care about Rust lifetimes. To implement that properly, you usually need ersatz typestates.)

The crucial bit for Vec::drain is in these two lines of code, which the article lists but does not discuss:

        // set self.vec length's to start, to be safe in case Drain is leaked
        self.set_len(start);

You cannot rely on Drop alone for safety, you need a fallback strategy in case of a leak (mem::forget or Rc cycle). Rust lifetimes only ensure that there is no use after free; there is no guarantee that Drop is called before the end of the lifetime. It's possible to mutably access the original Vec after leaking a Drain.

Thanks to the feedback in this discussion, the article now does discuss 5at line; much obliged to all the folks who helped me fix a substantial error.

Yeah that's the "pre" in "pre-pooping your pants"

This is misleading. `std::mem::forget(&'a mut v)` does not imply `'a: 'static`.

That is precisely what the post is about.

and fails to properly convey outright stating both in the title and places in the article that drop can be responsible for safety (it can't, in drain it's responsible for not leaking non drained elements, not safety)