What more do you want than what's covered in the post?

To me, this post is proof zig doesn't need "proper support". You can already have extremely ergonomic error payloads with existing language features.

Earlier version of this post had some language feature ideas, but then I realized Zig already had all the capabilities, so I just removed that section.

For example, I used to think it'd be nice for functions to be a namespace, so I didn't have `myFunc` and `MyFuncDiagnostics`. But then I realized that the Diagnostics type doesn't need its own name; you can just put the type in the function signature, and use a function like `diagnostics.OfFunction(fn)` to extract the type from the function definition, so you can just write this:

  var diag: diagnostics.OfFunction(myFunc) = .{};
  const res = myFunc(foo, bar, &diag) catch |err| ...;

As another example, I used to write out the `error{OutOfMemory, ...}` type explicitly in addition to the tagged union payload, but then realized you can generate an error set from the union tags at comptime.

Do you want automatic inference of the error payload type? So zig creates a special tagged union error payloads type for you automatically? It seems complicated and maybe not a good idea. Do you really want your function to return an invisible 20 elements union on error? Do you want to call a someone else's function which returns an invisible 20 elements union on error? You know, maybe it's not a good idea.