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 and here.
1 Like