[zokier]

Resource wouldn't necessary be something internal in the application, it could be also some external system or something like that. You might want to close TCP connections cleanly in destructors, or maybe more relevantly for embedded systems the resource might be some actual physical gadget that is activated/deactivated.

Of course this is all hypotheticals and it could very well be argued that relying on destructors to do something actually critical would be a bad design.

[monocasa]

> Of course this is all hypotheticals and it could very well be argued that relying on destructors to do something actually critical would be a bad design.

Eh, I'd only argue that in the case of garbage collected languages. In RAII languages like Rust and C++, it's the preferred way.

[twic]

There's a classic interview question about RAII along the lines of "in what situation can a RAII resource be acquired, but not released?". The key answer is "if someone turns the power off".

panic_fmt entering an infinite loop leads to pretty similar results as someone turning the power off. The stack will not be unwound, destructors will not be run, and bad designs will leave external resources in an inconsistent state.

[monocasa]

I mean, sure.

loop {}

^--- That'll also cause destructors to not be run.

[zokier]

Rust notably has slightly weakened RAII semantics: https://github.com/rust-lang/rfcs/blob/master/text/1066-safe...

tldr is that Rust does not guarantee that dtors are run

[steveklabnik]

C++ doesn't either, see http://stackoverflow.com/questions/7054685/are-destructors-r... for example.