3 ms·
> Having the allocator type be part of the collection type means every thing that needs to work with that collection also needs to be generic on the allocator t
by throwawaymaths 4y ago
> Having the allocator type be part of the collection type means every thing that needs to work with that collection also needs to be generic on the allocator type.
Maybe I'm misunderstanding but... Not necessarily? since zig is duck-typed at comptime, you could in principle pass the allocator in as a parameter "at runtime" and let the compiler figure out the allocator type.
- Arnavion 4y agofn reticulate(splines: std.ArrayList(u8)) void {} fn ArrayList2(comptime T: type, comptime A: type) type { _ = T; _ = A; return struct {}; } fn reticulate2(???) {} reticulate2 must work with all ArrayList(u8, A) regardless of what A is. So what is `???` ?
- AnIdiotOnTheNet 4y agofn reticulate2(splines2: anytype) void {} The compiler would ducktype splines2 and everything would work fine.
- Arnavion 4y agoYou lose a lot of type safety by making the whole parameter `anytype`. If Zig supported `ArrayList2(u8, anytype)` that would be marginally better, but it doesn't.
- throwawaymaths 4y ago> You lose a lot of type safety by making the whole parameter `anytype`. Pretty sure that's not the case. You can also put further compile time type assertions downstream of the function head. > If Zig supported I believe the argument of the thread is that it should support that.