Allocgate: Restructuring how allocators work in Zig

Re:Allocgate: Restructuring how allocators work in Zig by nikki93 on Wednesday December 15, 2021 @04:44PM (#29571991)

Not saying this means you actually need to add constructors and destructors, but I think the main tricky bit is when you have eg. a grow / shrinkable array and want to call something on it that removes elements and it should be calling destructors on those. AFAICT there's no clear place to add a `defer` that makes it happen at the right time at the lexical site those elements are originally added. I think this is where the main RAII complexity comes from vs. the lexical scope local variable scenario which is definitely handled by `defer`.

All that said, not an argument for having that, just wanted to nuance it. I think not having it and keeping the language focused on its priorities can be good, for example.

[ Parent | on HN ]

Re:Allocgate: Restructuring how allocators work in Zig by tialaramex on Wednesday December 15, 2021 @07:20PM (#29573280)

Surely the only part you need for this scenario is a way to dispose of whatever resources are behind the elements?

So if you have interfaces a Disposable interface is enough, the code can determine that these elements are Disposable and dispose of them when they're removed.

That's quite a lot less intense than needing a language-level concept of destructors. If you're writing a low-level language it might well be better to hook this in explicitly like Rust's Drop trait (the Drop trait is a langitem in Rust, it must exist), but in high-level languages I think you'd get almost all the value from a Disposable interface even if there is no actual language support provided.

[ Parent | on HN ]