Interestingly, I just read an article from matklad (who works a lot with Zig) talking about the benefits of splitting up error codes and error diagnostics, and the pattern of using a diagnostic sync to provide human-readable diagnostic information:
Honestly I was quite convinced by that, because it kind of matches my own experiences that, even when using complex `Error` objects in languages with exceptions, it's still often useful to create a separate diagnostics channel to feed information back to the user. Even for application errors for servers and things, that diagnostics channel is often just logging information out when it happens, then returning an error.
The separation of error codes and diagnostics is fine, but the language needs a standard mechanism to optionally pass this error diagnostic information. Otherwise, everyone will develop their own different way with ZERO consistency and many will simply not pass error diagnostics at all.
Your and GP's two statements are not mutually exclusive. This paradigm can have significant benefits, and at the same time be too cumbersome for people to want to use consistently.
I tend to follow the rest of the ecosystem when developing libraries. If i wanted to make a zig lib id look at what other major libs are doing (or not doing) and copy that.
If i found no consistency id be making a post like OP but from a different perspective.
If they want to keep to the error/diagnostic pattern I think they're gonna have to adopt some kind of standard context object that gets passed around. Passing an allocator, an IO implementation, and a diagnostic object all over your code base is going to get really fucking old.
if it helps: it's pretty typical to attach the allocator to the object directly, so you dont have to pass it everywhere. for library consumers, just build a global allocator and use that. io will just "have to be passed the annoying way" in libraries (but a consumer can also also easily globalize that).
I'm assuming you're talking about the "managed" pattern you'd see in stuff like Hashmaps and ArrayLists. To my knowledge that style is falling out of favor, and I think the managed versions will be removed from the standard library.
I haven't seen anyone use a global allocator in the way you're talking about, and if you did I feel like it goes directly against the Zig ethos. Part of the benefit of allocators being passed around is that all allocation are explicit.
https://matklad.github.io/2025/11/06/error-codes-for-control...
Honestly I was quite convinced by that, because it kind of matches my own experiences that, even when using complex `Error` objects in languages with exceptions, it's still often useful to create a separate diagnostics channel to feed information back to the user. Even for application errors for servers and things, that diagnostics channel is often just logging information out when it happens, then returning an error.