# Why is allocator an interface? **URL:** \ **Category:** Explain\ **Tags:** memory-management\ **Created:** [August 11, 2024, 11:15am UTC](https://ziggit.dev/t/why-is-allocator-an-interface/5589 "2024-08-11T11:15:01Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![LucasSantos91](https://ziggit.dev/user_avatar/ziggit.dev/lucassantos91/32/440_2.png) [@LucasSantos91](https://ziggit.dev/u/LucasSantos91)\ **Post date:** [August 12, 2024, 2:33am UTC](https://ziggit.dev/t/why-is-allocator-an-interface/5589/6 "2024-08-12T02:33:27Z")
> [@IntegratedQuantum](#): > > But if you use many different allocators and arenas(note that the arena type would also be generic over its child allocator type), then the amount of generated code might easily explode. If this becomes a problem, you can always switch to a type erasure (like the current `std.mem.Allocator`) and bring down the code size. Or you can limit the amount of allocators types you have, like define a set of 3 allocators that are allowed in your codebase, and you pick whichever one fits your use case the best, even if it’s not the perfect one for the job. I agree with @tgirod, in terms of generated machine code `anytype` is strictly superior to what we have today. In most cases you know exactly which allocators you are going to use in your codebase, and leveraging that information at compile-time generates better code. In the worst case scenario, you can use the `std.mem.Allocator` and you’re gonna get exactly the same code that we have today. The only real problem of `anytype` is that you lose ergonomics. It’s harder to read and tooling gets confused. I talked about this before [here](https://ziggit.dev/t/zig-code-smells/2928/3) and [here](https://ziggit.dev/t/the-cost-benefit-of-virtual-functions-and-interfaces/3502/11). --- _[View the full topic](https://ziggit.dev/t/why-is-allocator-an-interface/5589)._