3 ms·

RAII is not unavoidable though. The whole point of being against RAII is that forcing it has downsides you can not get away from. but Rust has mem::forget, an

RAII is not unavoidable though. The whole point of being against RAII is that forcing it has downsides you can not get away from. but Rust has mem::forget, and it is not even unsafe (it is in std only currently, but I see no reason why the kernel can not have its own version) So this to me seems a pointless argument vs: * calling the equivalent of drop() manually every time, except in some cases * calling mem::forget only when you need it and have auto drop() everywhere else ...Maybe mem::forget has not taken hold as a pattern? Still, these arguments do not look very technical , and much more religious to me

pdimitar 2y ago
Yep, all of what you said PLUS the fact that you can just use arena allocations where you know you'll have to allocate hundreds / thousands of objects and then free them almost at the same time. The blog article's author even alludes to this, which makes the post kind of funny. He debunked his own argument and yet continues on as if he did not.
laundmo 2y ago
re: std::mem::forget not being used much On one hand, its just a shortcut to moving a value into the transparent ManuallyDrop struct and forgetting the result. In most cases, ManuallyDrop is the preferred way, as it allows encoding this behaviour (disabling the built-in drop) on a type level. And if you want arenas or similar structures, they simply don't need to use either. The arena struct itself usually implements Drop to enact whatever it needs for deallocating the data its storing. The things stored in them also don't need ManuallyDrop since they're just written to memory directly using unsafe calls, and the compiler doesn't know this data exists (depending on implementation, some directly use syscalls, others use a Rust datastructure like Vec<u8> for allocating their memory). Nowhere in this is mem::forget or ManuallyDrop required, and the resulting API is usually far nicer than dealing with ManuallyDrop.

pdimitar 2y ago

Yep, all of what you said PLUS the fact that you can just use arena allocations where you know you'll have to allocate hundreds / thousands of objects and then free them almost at the same time. The blog article's author even alludes to this, which makes the post kind of funny. He debunked his own argument and yet continues on as if he did not.

laundmo 2y ago

re: std::mem::forget not being used much On one hand, its just a shortcut to moving a value into the transparent ManuallyDrop struct and forgetting the result. In most cases, ManuallyDrop is the preferred way, as it allows encoding this behaviour (disabling the built-in drop) on a type level. And if you want arenas or similar structures, they simply don't need to use either. The arena struct itself usually implements Drop to enact whatever it needs for deallocating the data its storing. The things stored in them also don't need ManuallyDrop since they're just written to memory directly using unsafe calls, and the compiler doesn't know this data exists (depending on implementation, some directly use syscalls, others use a Rust datastructure like Vec<u8> for allocating their memory). Nowhere in this is mem::forget or ManuallyDrop required, and the resulting API is usually far nicer than dealing with ManuallyDrop.