6 ms·
That would not compile because the append operation can fail, and errors cannot be ignored.
by AndyKelley 3y ago
That would not compile because the append operation can fail, and errors cannot be ignored.
- tialaramex 3y agoThe exact code written won't compile but it gets the idea across - the original claim from the blog post was just false as far as I can tell. We can't in fact be sure that no allocation took place just because we didn't provide an allocator. It's a convention at most, probably for code that's written by Zig programmers who prefer this style, it's true but you could say the same about any convention for any language.
- Arnavion 3y agoRight. The "will this or won't this allocate" analysis also needs to take into account all values being used by the code because they might be using allocators internally. I haven't written zig code in a few years so I don't know if people have developed a convention for it. That said, there is a reason types like `ArrayListUnmanaged` exist. If you have some complex type with a bunch of different collections as fields, you probably want to use the same allocator for all of those collections, so there's no reason to have the collections themselves store redundant copies of the allocator. Instead you can have the allocator held by the top-level type and use the `Unmanaged` collections as fields. This also means that you do end up needing to reference `self.allocator` explicitly when calling `.append()` etc, satisfying the original claim of TFA.