Zig Interface Revisited
4 comments
·July 16, 2025lenkite
thechao
I wonder if it's possible to not lock themselves into an ABI with a built in vtable implementation? I kinda get where they're coming from: let vtables be a user problem; but, yeah, modern compilers can do magic when they "know" the rules for built in vtables. It kinda feels like they're leaving a real performance opportunity on the ground?
kingstnap
You've put the
pub fn implBy(impl_obj: anytype) Logger
Function in a weird place. Normal practice is for the specific implementations to have a getLogger function to create the logger. For example, the allocators in Zig have you instantiate the top level and then call .allocator() on them to get the vtable + pointer to self.
It manages sanity a lot better, and the function implementations in the vtable can be private.
ozgrakkurt
Also can add compilation time as an upside to vtables.
And using vtable in code feels cleaner compared to using generics
Would it truly kill Zig to add native interface support ? All that ceremony is quite heavy and also somewhat error prone.
If nothing else, maybe they can add some helpers in the standard lib or codegen in the standard tooling to make stuff like this easier ? So one need not manually code all the function pointer types for methods and the dispatch in the interface type .
Yes, Zig is meant to be a low-level programming language, but stuff like this is basic table stakes nowadays. People will just make custom code generators after Zig 1.0 to do this exact thing - and they will likely be dozens of such custom code generators with subtle differences.