I presume it comes down to performance and memory requirements?
Since allocator represents truly type-erased runtime-polymorphic state (e.g. polymorphic layout - pointer to arena vs pointer to gpa), it makes sense to keep the interface as a fat pointer (anyopaque + vtable). It describes your complete state with minimum amount of data (ptr to state + ptr to behavior).
A reader/writer itself has a lot more common state, it isn’t a truly type erased interface in purest sense. It just makes sense to put the vtable inside, e.g. coupling vtable with all the state inside makes sense both at a system level (you can describe the complete state via a single pointer), but also it’s because you have static memory requirements (a reader/writer always has a known layout and always has a vtable and always has a buffer).
It also aligns with utilizing @fieldParentPtr
offers the same workflow as it does with SinglyLinkedList
, and the reasoning is pretty clear: firstly as you posted, performance. Having the state north of the vtable allows most interaction with the interface occur without a dispatch. Second is composition over inheritance. In this sense I would argue that the VTable is not actually “intrusive”. It’s inside the Writer object, not inside the FileWriter or any other specialization of the interface. An Allocator interface models polymporphism, strictly something that in C++ would be modelled via a single-level inheritance hierarchy and virtual methods (even though that would yield a sub-optimal layout strictly closer to the Reader/Writer implementation. I recommend a really cool video on the topic here.). A Reader Writer implements polymorphism via DoD - separating common functionality into a static type and then offering the implementation site freedom to integrate it however it sees fit via composition).