Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's no way to write a "destructor" defensively, if the contents of memory it is trying to "destroy" are undefined.

Whereas it's perfectly possible to only defer a statement when you know the "object" has been properly initialized.

That's why defer makes sense in a language like C (even Go), but RAII does not.



I agree with everything you've said, except the conclusion: C can't add proper safe RAII, but being "proper and safe" is not a threshold C even tries to uphold.


But would a destructor that runs automagically when a value goes out of scope, even if it's not properly initialized (and with zero regards for copies or moves) be in any way better than a defer that's explicitly called after it is initialized?

Cause, like, that's the entire thread.


Nope, it wouldn't be. I'm just pointing out that it being unsafe or hard to use is no barrier at all to it being in the language.


Hell, since RAII is an opt-in type-level infectious (in the sense that if you have an RAII member in a struct the struct is RAII) mechanism you can require that RAII structs be initialised.

Given the compiler would already need to know that a local is of an RAII type in order to insert the drop, move, and copy glues it’s not exactly a big requirement.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: