C++ vs. GCPRO

JV> Martin Buchholz <martin(a)xemacs.org&gt; writes: JV> I am still thing it might be a big win to use a C++ compiler to catch JV> GCPRO mistakes (if we really switched to C++ we could even have objects JV> GCPRO themselves). In fact I think a C++ compiler could catch mistakes JV> like the above at compile time. The idea is to make function arguments JV> and return values to have different classes with no implicit JV> conversion between them. In the same way you could catch most if not all JV> calls to functions that can GC from functions that cannot. [I still JV> haven't tried this so there may be some snag somewhere.] It is possible to have an object type (in the C++ sense) that would be an automatically GCPRO'ed Lisp_Object pointer, which would UNGCPRO on passing out of scope, but ... I don't think you can do anything do prove GCPROing at compile time, and I think in general the semantics of GC protection cannot be captured by a C++ object. Consider: Lisp_Object bar (Lisp_Object); ... bar (Fcons (Qnil, Qnil)); Temporary variables can't be handled. On the other hand, if we could switch to C++ permanently, at least GCPROing would be less painful. BEFORE: { Lisp_Object foo, ret; struct gcpro gcpro1; foo = Fcons (Qnil, Qnil); GCPRO1 (foo); ret = bar (foo); UNGCPRO; return ret; } AFTER: { Protected_Lisp_Object foo = Fcons (Qnil, Qnil); return bar (foo); } What's going on is just as tricky - merely less annoying to code. You still must resist the urge to write { return bar (Fcons (Qnil, Qnil)); } A function can't return a Protected_Lisp_Object, only a Lisp_Object. I'd like you to prove me wrong - in this case I would support the permanent switch to C++.