Safer Core Library C type names

[scolsen]

The emitted names for some core library C types can conflict with definitions in other headers. For example, I'm trying to use some generated Carp C along with Apple framework headers--unfortunately one the the framework headers defines Pattern as a struct, while core defines it as char*

Should we prefix the emitted C names of core types to avoid this situation? e.g. CARP_Pattern? Or at least expose this as a compiler option?

[scolsen]

similarly, delete is a keyword in objective-c++ -- so if that's something we'd want to support eventually we'd need ways around that to

[scolsen]

We'll also need explicit casts in some cases in core to compiler with under c++

[scolsen]

Thinking about these issue a bit more—I suppose the first question we should answer is whether or not we care about C++ compatibility. After all, C and C++ are two different languages. It might be best to stick to one and leave the rest up to particular project maintainers, if needed. That said, when it comes to code that's valid in C and C++ but only required by C++ (e.g. explicit casting of void* during initialization, maybe it'd be helpful for us to support that?)

[eriksvedang]

I think this suggestion makes sense. Supporting C++ would definitely be nice, since it's such a common language for useful libraries. Prefixing sounds good.