> I think it really is not obvious once you start thinking about all the implications.
No... it really is obvious. I've written quite a bit of C, C++, and Rust over the years, in addition to all sorts of garbage collected languages. I'm not writing this as an off-the-cuff thought. I've even written a similar comment before on HN about Zig's error handling. I've thought about this for a long time. It is just as obvious now as it was on day one.
The fact that the Zig team keeps resisting this is just mind blowing to me. "Penny wise, pound foolish" is my opinion. The actual runtime cost here would be so entirely negligible, but its absence is a major limitation.
> The advantage of this system is that the caller can decide whether error diagnostics are desirable or not. If they're not, then zig-clap doesn't waste cycles nor memory keeping track of the context in which an error happened. It's the best of both worlds in my opinion.
Instead, the developer has to waste mental cycles and memory keeping track of the context on every single function call. Strongly disagree on it being the best of both worlds.
For starters, every library has to decide whether they will support it or not. If the language doesn't make this a built-in part of the core error handling, then spoiler: they won't. They'll throw away all useful error context, leaving no option for the application developer to add it back. Once the context is gone, it's gone for good. You can't know what a library did to cause an AccessDenied error... you can't reach into the library and pull that context out of thin air. If every library is implementing this diagnostics pattern, then that's an equally strong argument for it to be supported at the language level. Either context is being irrevocably lost or developers are wasting time writing convoluted code. Either way, this is not the optimal solution.
I have experience writing code in a lot of languages... error context is extremely important, and the "waste" of CPU cycles and memory is extremely minimal for the benefit gained.
As I have hinted before, a compile-time switch to throw this information away could be a valid solution for the extremely-difficult-to-imagine situations where great error handling is unacceptably costly on performance... then it would be like Zig's "async" support, where the library developer doesn't have to color their functions based on how the end user will use it. They should return all the error information all the time, and the compiler decides whether to keep the context or throw it away and provide only the error "name". Yes, this would bring its own challenges, but seriously, this option to discard the context is completely unnecessary outside of like 8-bit microcontrollers, and probably isn't worth implementing. Just provide context all the time. Please... it's such a small ask.
Looking at the links you've provided, which you have also provided in past discussions here, that pattern is extremely painful. I cannot overstate how much worse that usability is compared to the regular error handling Zig provides, and so obviously no one will ever use it. It serves as a pattern for the most desperate situations, and as a way to handwave the lack of language-level support for error context, in my opinion.