mem::forget isn’t the only way you can safely leak a value, you can do it with reference cycles too, right? And there is no way for the compiler to detect that?

Isn’t that why mem::forget is safe, because you can always implement it yourself safely? How do you get around that?

▲

stymaar 6 hours ago | parent | next [-]

> mem::forget isn’t the only way you can safely leak a value, you can do it with reference cycles too, right? And there is no way for the compiler to detect that?

But there's an easy solution for that: you make the reference-counted smart pointers require their pointee type to be Forget. It will be like how Arc<T> doesn't implement Send unless <T: Sync>.

▲

klauserc 41 minutes ago | parent [-]

An alternative way to "forget" a value is to hand it off to another thread that then loops infinitely.

Could of course be plugged by saying `!Forget : !Send`, but wouldn't that preclude legitimate useful scenarios for `!Forget`?

	▲	aw1621107 33 minutes ago \| parent [-]
		> An alternative way to "forget" a value is to hand it off to another thread that then loops infinitely. Might be able to address that by only allowing such a handoff to a thread spawned via some scoped abstraction to ensure that progress can only be made if/when the spawned thread terminates?

▲

skitter 6 hours ago | parent | prev [-]

By doing the same as with `Sized`: Automatically including the `Forget` bound on generic parameters and letting methods that don't need to be able to forget them opt out. That way existing code continues to compile and existing unsafe code doesn't become unsound.