I’ve always wanted to write a compiler so perhaps I’ll experiment with some of the following ideas one day.
Keywords that support some kind of package system should
should be some keyword for text substitution. If this wish
and my previous wish were granted, the preprocessor should
not be needed. (Recall conditional compilation should be left
to the build system.)
After writing the first version of a function, often I want to have the function return more data, such as an error code or diagnostic data. I’m forced to add an extra pointer parameter, somehow encode it into the return value, or define a one-off tuple struct. Multiple return values would be much simpler.
I often only require one call to a nested function; anonymous functions would simplify the code.
Once in a while, I need to break out of a nested loop. I can either add a helper function (which isn’t too bad because I use nested functions), or add a flag. I’d like a simple keyword instead.
I sometimes have a need for string literals that span multiple lines. Python has a triple-quote delimiter for this case. I wish C had something similar.
Arrays indexed from ranges other than [0..N-1] sometimes better fit the problem at hand, for example, an array of triangular numbers. The venerable "Numerical Recipes in C" advocates this hack:
float b, *bb = b - 1;
The elements of
supposedly be referred to as
bb. Unfortunately, section 6.5.6 of the
C99 standard appears to state the results are undefined,
though it may work for many compilers.
During runtime, I would like to be able to take a regular expression and have it compile to native machine code which other code could subsequently call. Incidentally, by "regular expression" I don’t mean POSIX regular expressions; I mean regular expressions which truly map to regular languages and can be matched in linear time.
The previous wish is a form of reflection. Full reflection may be difficult to add to C, but I wonder how far one can go.
There may be no elegant way to retrofit true closures into C, but if there is, it could simplify code.
Previous chapters suggest other ways to improve the language. Break in switch statements should be the default, and fallthrough should be exceptional. Type promotion and implicit casting should be removed, except perhaps from void *. The conventions for symbol visibility should be reversed, that is, public exposure should be opt-in, not opt-out. Similarly for static versus extern functions. Bitwise AND and OR should have higher precedence. An exchange operator for basic types would be convenient. Syntax flaws should be fixed.