The problem errdefer solves is “resource passthrough” where a function needs to acquire a resource, do some faillible processing, and return the resource.
In case the processing fails, the resource needs to be released, which an unconditional “defer” is not great for (now you need extra flags).
But RAII solves the issue, in case of failure you just don’t return the resource, and it gets released. Likewise linear types, if you don’t return the resource you will have to explicitly release it.
Errdefer only adds a workaround, because now every time you acquire a resource you need to question how it interacts with the call stack and whether you need to defer or errdefer it, and any change to the function requires reconsidering this question.
RAII uses destructors. Destructors are a language feature that is even more ad-hoc than errdefer. Instead of writing general-purpose functions, you need special functions for construction and destruction. That's bad design.
errdefer is not just used for destroying objects either, no more than functions are only used for constructing objects.
That seems loaded enough in your mind that it aliases to untrue. RAII uses some sort of type-associated operation. How that type association is reified is up to the language.
> you need special functions for construction and destruction
That is not true. You don't need any special function for construction, and for destruction you only need a hook. Which is no more special (and arguably less so) than the hook you need for either defer or errdefer.
> Destructors are a language feature that is even more ad-hoc than errdefer.
I'm not sure you understand what the expression "ad-hoc" means. "errdefer" is an ad-hoc feature, it has a very narrow and specific purpose. RAII is a much more generic feature, for instance it subsumes both defer and errdefer, as well as other patterns of resource management.
> errdefer is not just used for destroying objects either
Good news: neither is RAII. Object destruction is the hook onto which RAII attaches, not the purpose.
Exactyl! It is RAII (or linear types) with the addition of a "contextual computation" and syntax for it, so that multiple calls can be done in an ergonomic way.
Ah so we need three or four additional language features to do it, and PhDs in category theory.
...or you could accept that not every language needs to be a Haskell clone, and there is more than one good way to design a language. Choices have tradeoffs. The choices Haskell and Rust make are not the only valid choices. They have costs.
Not really, you don't even need a specific language feature to model RAII, except for some basic ones like function lambdas to make it ergonomic to use.
It also doesn't really have anything to do with Haskell, it really is language agnostic.
The problem errdefer solves is “resource passthrough” where a function needs to acquire a resource, do some faillible processing, and return the resource.
In case the processing fails, the resource needs to be released, which an unconditional “defer” is not great for (now you need extra flags).
But RAII solves the issue, in case of failure you just don’t return the resource, and it gets released. Likewise linear types, if you don’t return the resource you will have to explicitly release it.
Errdefer only adds a workaround, because now every time you acquire a resource you need to question how it interacts with the call stack and whether you need to defer or errdefer it, and any change to the function requires reconsidering this question.