感觉zig的defer没有c++的raii和rust的drop好用

[xinyang-go]

该问题主要存在于泛型类中。

例如容器在deinit的时候没法把保存在容器中的元素也deinit。ArrayList(ArrayList(i32))在defer的时候得手动先把内部deinit再把外部deinit。
虽然可以通过反射判断元素是否存在deinit函数，来选择性deinit元素，但依然存在两个问题：

• 没有任何语言上的强制性要求，让元素的析构函数名称必须叫deinit。
• deinit可能需要传参，常见情况是传递一个allocator，但也有可能存在其他传参。

[Ariaszzzhc]

zig 毕竟讲究没有隐式执行流。ArrayList(ArrayList(i32)) 在 deinit 的时候如果把内部也 deinit 就不符合 zig 的原则了。
只能说有利也有弊，阅读代码的时候确实很直观很方便，写的时候很累人（人总是要偷懒的

[David-G96]

最简单的办法就是把结构包装一下。不过我认为zig的做法是正确的，因为析构或者说释放一些资源是一个多方面的动作，对于没有分配器的C++/Rust来说可以直接释放，但是一旦遇到了“部分所有权”，“不完全所有权”，还有许多底层操作的话RAII/Ownership就会变成地雷。支持泛型但是不支持接口/特征也加重了这一点问题，不过既然zig不是HM类型的ML，这倒是保持了内存透明也挺好的。

[AlphaFoxz]

我认为语言最重要的是自恰，如果存在隐藏逻辑能把内部的一起析构，那么这个feature在当前版本的zig就变成了一个异物。zig还没有发展到把这种东西纳入进来的程度（也有可能是不会往这个方向发展）

[ufbycd]

Rust的所有权概念诞生于C++的RAII的局限性。可以认为是RAII的缺陷催生了Rust。从这方面理解就可以知道Zig的defer是对的。

[lujiaguo]

zig 提供了足够灵活的工具来管理内存,
嵌套容器 deinit 可以考虑使用 ArenaAllocator

[violeshnv]

想要 RAII 的好处就要接受它的坏处，比如 C++ 的 move/forward 就是给 RAII 打补丁，还弄出一套复杂的析构语义、左右值语义