[dwattttt]

You mandate it like you mandate anything else in C. You don't.

You pick C because you want a language that doesn't require a variable to be initialised before mutably referencing it, and you write your defer statements or "destructors" defensively, expecting that a variable could be in any state when it comes time to dispose of it.

Or if you find that unacceptable, you accept that C isn't the language you want. There's many other choices available.

[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.