Allocgate: Restructuring how allocators work in Zig
pithlessly.github.io
Allocgate: Restructuring how allocators work in Zig
1–10 of 52 posts
Re: Allocgate: Restructuring how allocators work in Zig
#2Does anyone know if RAII types will ever be a thing in Zig?
Re: Allocgate: Restructuring how allocators work in Zig
#3This was a fantastic, thorough explanation, thank you for putting in the effort!
Re: Allocgate: Restructuring how allocators work in Zig
#4Does anyone know if RAII types will ever be a thing in Zig?
maybe since Zig still is making breaking changes, they can call it IIRA
Re: Allocgate: Restructuring how allocators work in Zig
#5Does anyone know if RAII types will ever be a thing in Zig?
`defer` and `errdefer` give you 90% of what destructors & co give you for 0% of the complexity.
For now the the closest thing to RAII is this proposal, but there is no guarantee that it will be accepted.
Re: Allocgate: Restructuring how allocators work in Zig
#6Does anyone know if RAII types will ever be a thing in Zig?
`defer` and `errdefer` give you 90% of what destructors & co give you for 0% of the complexity. For now the the closest thing to RAII is this proposal, but there is no guarantee that it will be accepted. https://github.com/ziglang/zig/issues/782
I find in C++ at least reasoning about RAII is always surprisingly complex. The second you have to write a custom destructor you get into the weeds of reasoning about copy/move/copy-assignment etc.
https://en.cppreference.com/w/cpp/language/rule_of_three
C++ RAII also rubs up painfully against handle based APIs (looking at you Windows) in my experience. There is a lack of standardized RAII wrappers for handle types like there is for pointers. Yes you can pull in a custom handle RAII wrapper but at that point it's simpler to just manage manually.
Defer on the other hand is simple. Anyone can understand it in five minutes.
Re: Allocgate: Restructuring how allocators work in Zig
#7why not just an an interface type instead of this giant mess?
Re: Allocgate: Restructuring how allocators work in Zig
#8Does anyone know if RAII types will ever be a thing in Zig?
When people talk about RAII in relation to Zig I think they mean something slightly different than RAII, but then the conversation starts to become about what is the definition of RAII rather than whether the Zig language is lacking a certain kind of useful abstraction.
Examples:
[1]: https://news.ycombinator.com/item?id=29506814
[2]: https://gist.github.com/andrewrk/190170bc1441839644c3f15725a...
Re: Allocgate: Restructuring how allocators work in Zig
#9Does anyone know if RAII types will ever be a thing in Zig?
`defer` and `errdefer` give you 90% of what destructors & co give you for 0% of the complexity. For now the the closest thing to RAII is this proposal, but there is no guarantee that it will be accepted. https://github.com/ziglang/zig/issues/782
I'm pinning my hopes that certain types can be marked as "shared resources", either in-lang, or through a minimalistic helper tool - and analyzed at a lower level (ZIR or AIR) for lifetime analysis.
Re: Allocgate: Restructuring how allocators work in Zig
#10Does anyone know if RAII types will ever be a thing in Zig?
It's unlikely. RAII comes with a surprising amount of complexity. In order to have a reasonably complete language that has RAII and value types, you must also have:
- constructors
- destructors
- overloadable copy assignment operators
- placement new
- move semantics and rvalue references
These features come together or not at all. If you lose any of them, the language becomes less complete. I think Rust and C++ are doing a fine job of exploring the design space of languages that have this feature set, but it's too much complexity for Zig.
Edit: As commenters have pointed out, this exact manifestation of these features is not required. A more correct set of requirements is:
- a notion of beginning and ending object lifetimes in existing memory
- a notion of move semantics to relocate an existing RAII object
- a notion of non-copyability for certain types, or an ability to override copy behavior