I respect Jean-Heyd very much, but I'm unconvinced by this article.
First, the whole name mangling discussion is completely irrelevant to the issue and can be omitted. Second, one could tack on both copy and move constructors on to C in order to solve the double-free issue, in much the same way regular ctors are tacked on in the email proposal. In fact, I would argue that it is _necessary_ because A in RAII stands for Acquisition not Allocation. "Acquisition" implies ownership, which can be transferred or shared, so your copies and moves _have_ to have a special meaning to them. The fact that the proposal is bad or incomplete does not mean that it is "impossible" to have RAII in C. I don't claim that it _is_, but reading this did not reveal to me anything fundamental that would preclude RAII, only that all the preceding RAII proposals have been sloppy.
I found the arguments compelling. The discussion on "Effective types" and C not having a proper concept of objects is key.
Another way to think about it: even if you had defined constructors and destructors for a struct, you have not solved when to call them. C++'s answer to that question is its sophisticated object model. C does not have one, and in order to answer that question, it must. It's worth noting that RAII was not a feature that was intentionally created in C++. Rather, astute early C++ developers realized it was a useful idiom made possible by C++'s object model.
You say "just add copy and move contructors", but that requires function overloading, which is exactly why he spent a third of the article ranting about name mangling. The point is that there is a tangled network of interdependent features that make C++ work, and you can't ""just"" take a small piece to put into C without dragging a whole bunch of other stuff along.
Yes, it meanders to much to get to the point. Which is that RAII doesn't work in C because unlike C++, which has a comprehensive type system mandated by a standard, a C program doesn't "know" at runtime that a struct is composed of other (typed) fields so it can do a proper deep field copy (or destruction). And implementing that type system in C doesn't seem feasible for practical and political reasons.
I think the actual question should be "can C get automatic memory management like in C++ without having the equivalent of C++'s type system"?
Though I can't put my finger on it, my intuition says it can, if the interested people are willing to look deep enough.
In C++, when you copy a struct instance to another instance, the runtime knows if any fields (to whatever depth) have manually defined assignment or move operators and will call them in the proper order. So it's a deep copy. The same information is used for calling any field constructors and destructors that are user defined.
Introspection (reflection) would go even further and provide at runtime all the information that you have at compile time about an object. But that's not required for assignment and destruction operations to work.
C doesn't have any of that, so a struct copy is just a shallow copy, a bit by bit copy of the entire struct contents. Which works pretty well, except for pointers/references.
No. Well, yes, in that if the type of an object is dynamic, it's possible that certain functions are resolved at runtime usually through a "virtual table". The static type of an object is only known at compile time, and all that the virtual dispatch does is an indirection through the virtual table to the static constructor or destructor as required, and the static special functions always know how to construct, copy, or destroy any subobjects.
So, no, runtime introspection is not needed, but runtime dispatch may be needed.
