[ncruces]

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.

[dwattttt]

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.

[ncruces]

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.

[dwattttt]

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.

[masklinn]

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.