No Us Without You: elifdef and elifndef

I think it was unfortunate that the C preprocessor syntax is completely different from that of the C language itself. PL/I's preprocessor syntax is (approximately) a subset of the normal PL/I syntax (with a % sign in front to distinguish preprocessor instructions from code). I think that's a better approach.

That said, there is so much C code in existence assuming the existing C preprocessor, it is more feasible to add new features to the existing one than replace it with something new and incompatible.

I wish they'd add some better syntax for multi-line macros. So instead of:

  #define TRY(what) \
      do { \
         int r = (what); \
         if (r != 0) \
            return r; \
      } while (0)

you could write something like this:

     #macro TRY(what)
        do {
           int r = (what);
           if (r != 0)
               return r;
        } while (0)
     #endmacro

Get rid of the backslashes (which are easy to screw up). It would also enable you to use #if conditionals inside the #macro block, so you could easily write conditional macros.

Also, maybe instead of the do { ... } while (0) trick, #macro could automatically insert do { } while (0), maybe say if the #macro had a { on the same line:

     #macro TRY(what) {
        int r = (what);
        if (r != 0)
           return r;
     }
     #endmacro

Some kind of looping support (e.g. #while) would also be great:

     #macro NULLS(count)
     #   local i 0
     #   while (i < count)
             NULL,
     #       define i i+1
     #   endwhile
     #endmacro

In the above, #local is #define but local to the #macro block.

I think it would have been much better to design an alternative with the same feature set (i.e. code generation through substitution), but better overall design in terms of hygiene and scoping, as opposed to what C++ has been trying to do by making ad-hoc replacements for some of the tasks you would want to use the preprocessor for, and then admonishing anyone who uses it because of limitations in the replacements. Macros are fundamentaly extremely useful, and the CPP is bad because it's a bad implementation of the concept (as well as leant on far too hard for importing interface definitions), not because the concept itself is bad.