[HN Gopher] Zig Interface Revisited
___________________________________________________________________
Zig Interface Revisited
Author : ww520
Score : 64 points
Date : 2025-07-16 16:52 UTC (3 days ago)
(HTM) web link (williamw520.github.io)
(TXT) w3m dump (williamw520.github.io)
| ozgrakkurt wrote:
| Also can add compilation time as an upside to vtables.
|
| And using vtable in code feels cleaner compared to using generics
| kingstnap wrote:
| 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.
| lenkite wrote:
| 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.
| thechao wrote:
| 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?
| wavemode wrote:
| There's just one feature Zig lacks, which would have allowed
| for full automation of interface definitions. In Zig you can
| programmatically construct data types with compile-time
| programming, but such types aren't allowed to have methods:
| https://github.com/ziglang/zig/issues/6709
|
| This is an intentional limitation, because the language creator
| worries the feature would be abused.
| hmry wrote:
| I strongly dislike "this feature could be abused, so we won't
| add it" as reasoning for language design decisions. It just
| doesn't sit right with me. I'm fine with designing to avoid
| "misuse" (i.e. accidentally shooting yourself in the foot),
| but avoiding "abuse" just reads as imposing your taste onto
| all users of your language. I don't like this, so nobody
| should be able to do it.
|
| But oh well, if you're using Zig (or any other language using
| auteur-driven development like Odin or Jai or C3) you already
| signed up to only getting the features that the benevolent
| dictator thinks are useful. You take the good (tightly
| designed with no feature bloat) and the bad ("I consider this
| decision unlikely to be reversed").
| leagreeer wrote:
| Agreed that native interface support is table stakes for any
| language now. It would avoid so much boilerplate - nevermind
| the time wasted examining the code to see what kind of ad-hoc
| interface any given piece of code is using - and how to
| retrieve the ridiculous zig vtable data member for each pseudo
| class instance. It just amounts to useless noise in the code,
| rather than succinctly stating the intent.
| throwawaymaths wrote:
| > nevermind the time wasted examining the code to see what
| kind of ad-hoc interface any given piece of code is using
|
| this is not really a problem I've encountered. did you have a
| specific case where you got puzzled?
| throwawaymaths wrote:
| > somewhat error prone
|
| do you have any evidence for this? what is the error you're
| proposing here?
| int_19h wrote:
| This is like the inverse of the normal C++ vtable. Normally the
| whole point of having a separate vtable (as opposed to just a
| bunch of function pointers directly in the struct) is so that you
| can share a single one between all instances, at the cost of one
| extra indirection. But here a copy of the vtable is instead
| attached to one individual instance, and yet it still does this
| one extra indirection to get to the implementation object.
| andsoitis wrote:
| > That doesn't mean polymorphism is off the table. In fact Zig
| has the tools to build interface-like behavior, making dynamic
| dispatch possible.
|
| Do all code bases use the same pattern? Or does it not matter for
| interoperability, e.g. between an app and the libraries it
| consumes?
| leagreeer wrote:
| > Do all code bases use the same pattern?
|
| Unfortunately no - it's a complete free for all - which is the
| problem. Conventions are great to a point but language enforced
| constructs are better.
___________________________________________________________________
(page generated 2025-07-19 23:00 UTC)