Why are Writers not fat pointers like Allocators?

[fading coyote]

Hi. I noticed something ...

An Allocator consists of a pointer and a vtable. The various allocators from std all have an allocator() method that returns an Allocator with pointers to the relevant context and functions. This allow other functions and structs to accept an Allocator as a parameter and field.

A Writer is a function (generic type) taking a comptime with a context type, error type, and write function pointer. The various things from std that can be written to implements a writer() method, but these must return a Writer(...), typically defined in the same scope. Therefore, functions that use a writer as parameter usually use writer: anytype, such that they can accept any writer. Moreover, it is not possible to store an arbitrary writer in a struct.

Why was the Writer (and Reader) designed this way? Why do they not use the same pattern as Allocators? This would allow them to be stored in a struct, make function signatures better, and help the lsp too.

[fading saddle]

Writer and Reader are comptime interfaces. Allocator is a runtime interface.

In the Allocator vtable there are function pointers, in Writer and Reader you just pass the functions themselves as arguments.

[fading coyote]

Yes. But why? Why is that an advantage? Is is wrong to store a Writer in a struct?

[fading saddle]

You can store a writer in a struct. The advantage of having functions at comptime is that you don't need to do an indirect call, which is slow.

I don't know why they chose to make allocators runtime and writers comptime. Anyone know?

[haughty root]

I recall https://pithlessly.github.io/allocgate.html was a good explanation of the Allocator decision

[fading saddle]

nah that just explains why we ditched fieldparentptr

[raven inlet]

it's not wrong, but it is trickier than it seems on the face of it, as you need the specific Writer type (e.g. you can't store an io.Writer, you have to store an io.BufferedWriter or whatever)

but that can be worked around via comptime type construction

[fading coyote]

Interesting read nevertheless. Performance and api benefits

The natural question is now: Have we investigated in a similar api would have performance benefits for Readers/Writers? 😉

Probably not due to comptime stuff, but would be nice with the consistent api

[fading saddle]

definitely not

[raven inlet]

the current thinking (i believe) is: does the build system need a runtime writer to exist. if not, it won't go into std

[fading saddle]

thats a terrible rationale for "what needs to go into std", but whatever

[limber bison]

iiuc the original rationale was because readers and writers need to deal with async

and dealing with async through a purely runtime interface is not very fun

[fading saddle]

ah

but the function types writer accepts aren't async

[raven inlet]

this got in my head a bit so https://gist.github.com/DaJobat/55e0703a6841251a5b58402bc324ff9d

this is essentially a very barebones fat pointer wrapper for a Writer

[fading coyote]

Very nice

[raven inlet]

obviously it doesn't implement all the io.Writer functions, you'd have to put them all in to make it properly drop in to functions but it's a start

also it's gross don't do it

[tardy pawn]

afaiu, Writer is a comptime interface b/c its impls can specify different error sets for the write function, and that requires a comptime parameter to do

[cinder panther]

@fading saddle read and write only have to comply with the interface, it can still do async, doesn't care

[fading saddle]

👀 osuHOW

[limber bison]

zig's async is colorblind

[fading saddle]

go on

[deft shuttle]

if a function isn't marked async but it calls async functions it becomes async itself

generic code can call non-async and async functions in the same way and the asyncness extends to the generic code