Builtin friendly interface as includes

[graphitemaster]

In response to __builtin_typeid #8 I think it would be better to implement a re-directive interface in header files once we have a CPP (see #2). This way if existing code some-how (for which ever insane reason chooses to use variable names like "typeid" the code will (and should still compile). Much like how in C, bool only works if you #include << stdbool.h >>. This sort of support would do something along the lines of:

include << stdtypeid.qh >>

which would simply do something like

define typeid [[extension]] __builtin_typeid

It's important to provide [[extension]] specifiers here for two reasons.
-1 IT hints the compiler that the code is using an extension (which implies that we can skip the entire check of variables and hit the compilers builtin intrinsic logic (to do what needs to be done).

-2 IT prevents people from using __builtin_typeid the same way the compiler would. So we can warn that it's an extension or even error, and that it would be better if they #include << stdtypeid.qh >>

[graphitemaster]

I should note that [[extension]] is the C++11 attribute syntax (I don't actually care how that's implemented) It could be in the form of an attribute(extension) or literally anything else that seems less ambiguous.

[Blub]

I'm against making an include file change the behaviour of some keyword.

Actually I'm even against having standard-includes at all, but we can talk about adding #pragma to enable/disable them. (preferably though a simple compiler-switch should do the job)

[graphitemaster]

I don't mind the pragma concept to enable extensions, but I much fathom that we implement [[extension]] code specifiers for any internal code (perhaps future standard library/interface code we may add). They're great for various hinters to say "hey Mr compiler, instead of searching the entire scope for variables of that name, then hitting the global scope, searching for X ... instead just hit the extensions subsystem and check if it's an extension" (which would save some time on contention). Of course they also go hand-in-hand with SAL if someone ever wants to write a nice integrated development environment for QuakeC (which I might even do some day).

[graphitemaster]

Closing this as it isn't really a requirement.