> You can emit an error/ok union and have the error return the structured information.

I already addressed how you’re apparently giving up all of the benefits of Zig’s error handling system to do this. That level of convention breaking isn’t a good sign for anything. The current convention really is that bad, from my point of view.

The obvious solution’s extremely tiny overhead could “easily” be avoided in the almost non-existent cases where it matters.

I want robust software by default, not software where I have to use side channel hacks to get the information I need by default... but maybe that’s just me. (And everyone else who upvoted that GitHub issue)

Of course Zig programmers would be unlikely to see the issue here — naturally the people left are the ones who don’t see the problem. People like myself who know from past experience how problematic not having error context is are likely to just avoid Zig until it meets our minimum requirements.

That’s not a problem for existing Zig users — it works for them — but it is annoying to people like me who think Zig otherwise has a number of interesting aspects.

You're missing the point. Let me give a direct analogy: In erlang there is a fantastic error system, but sometimes you want to emit an ok/error tuple instead. There is a generally sane heuristic of when you do and don't want to use the error pathways, it's a part of making good engineering choices. Generally speaking it's the case where when you want structured errors you use the tuple.

It's possible that erlang developers are merely internalizing sone pain, but it's also a robust system that people have been developing highly reliable and broadly used (e.g. rabbitMQ) systems architectures in, so the choice can't be all that bad.