[bsder]

No ... this isn't C.

Will it have IDE support for the abstraction? Will a syntax mistake explode with a non-sensical error (yes, in this instance, because you are splicing macros and a syntax mistake will splice weird)? etc.

If you want C with Generic Types, use C++. Rather than splicing unknown garbage onto C, use a subset of your C++ features and you will get full IDE support, proper template errors (okay, maybe not an improvement), proper elision and inlining, etc.

[spacedcowboy]

> No ... this isn't C.

My test for whether something or not is "still C" is very simple... "Does it compile with a C compiler"

These compile. They're C. End of debate.

Whether something has IDE support is neither here nor there. When I was learning C, your IDE was "vi" and "csh"... It was still C.

As for errors, completely normal C code can spew out errors up the wazoo if you miss an errant ;, " or } (to pluck examples out of the air) somewhere important, things like "function not defined" because you were using a function later on in the file and it can no longer be parsed. Error quality does not define the language either.

[usrnm]

All C compilers can do inline asm, is asm C too?

[spacedcowboy]

Jeez, there's always one..

Fine. My test for whether something consisting of C keywords, variable names, and symbols expected within the language as per the definition by some publicly agreed standard such as "C17", "C99" or "K&R", abhorring any non-standard extensions, other languages, or practices outside of the provided pre-processor, assembler and linker, and excluding any non-standard keywords that may or may not result in correct output, as pertaining to underlying architectural differences, is "still C" is very simple... "Does it compile with said C compiler"