[martinhath]

How would errdefer work in the general union setting?

Having errors as a first class construct in the language allows things like errdefer to be very simple and easy to use. It looks needlessly specialised at first, but I think it’s actually a really good design.

[valenterry]

That's a very good question! Most advanced languages have some way of defining the concept of a "computation within a context". For example, all languages that support a notion of Monads do have that kind of support. Examples would be Haskell, Scala, F#, ...

In those languages there are (or would be) generally two ways of achieving the same thing as errdefer:

1.) having a common interface/tag for errors

In that case, if you have a return type "success | error1 | error2" then error1 and error2 must implement a common global interface ("error") so that you can "chain" computations that have a return type of the shape of "success | error". "success | error1 | error2" would follow that shape because the type "error1 | error2" is then a subtype of "error".

2.) Having some kind of result type.

This would be similar to how it works in rust or in the example in the article here. So you would have a sumtype like "Result = either success A or failure B" and the errors that are stored in the result-failure (B) would then be uniontypes.

The chaining would then just be a function implemented on the result-type. This is personally what I use in Scala for my error handling.

Just to make it clear, this "chaining" is not specific for error-handling but a very general concept.

[masklinn]

> How would errdefer work in the general union setting?

Well it could not be, and some would argue that would be better.

But you could also have a blessed type, or a more general concept of "abortion" which any type could be linked to.

Or you could have a different statement for failure returns that way you can distinguish a success and a failure without necessarily imposing a specific representation of those failures.