4 ms·
With regards to RAII (as in constructors/destructors, not the stuff in the issue you linked), I think it simply didn't fit within Zig's goals. A big part of Zig
by c0ast 5y ago
With regards to RAII (as in constructors/destructors, not the stuff in the issue you linked), I think it simply didn't fit within Zig's goals. A big part of Zig is readability; what you read is what you get, and RAII is very much not that. Looking at a block of C++ code, there's no way to tell what happens unless you also know what the constructors/destructors of each data type in the block does.
- PoignardAzur 5y agoI wonder if Zig could add a "mustbedestroyed" annotation to a type, that doesn't actually add RAII-style invisible code, but forces developers do add 'defer' instructions to code that creates instances of the type. EDIT: Aaand shockingly, I'm not the first to come up with this idea: https://github.com/ziglang/zig/issues/782 https://github.com/ziglang/zig/issues/782
- lenkite 5y agoDestructors don't do any strange thing in C++ apart from closing allocated resources - so in reality you always know what happens. This presents mistakes and decreases code length in calling code.
- adrusi 5y agoAnd more concretely, a language design rule of thumb in Zig is that if a function is called, there should be an explicit function call. Zig offers defer and errdefer as the closest substitute for RAII that makes all calls explicit.