Mixin versus c++ preprocessor?

[Tim Burrell]

Tom S wrote:
> Tim Burrell wrote:
>> Mixins are great, but in no way a replacement for the C preprocessor.  I 
>> think it was a big mistake to not include preprocessing as well.
> 
> It's not like a preprocessor could not be used separately... It might 
> not be standard, D-wise, but most non-trivial software has a complex 
> build process.
> 
> Preprocessing a single specific file in a project is much lesser a sin 
> than including a standard preprocessing stage in the compiler, IMHO.

Yeah it's definitely true.  And I know this... it's just more work to 
set up a separate preprocessing tool, adds another project dependency, 
etc.  For the kind of things I'd want to use a preprocessor for (super 
quick and simple search and replace style defines) adding a whole 
preprocessor is way overkill.

The problem with the C preprocessor is it became too powerful, and can 
lead to some bad design choices -- stuff that's hard to maintain, port, 
comprehend, etc.  I can see why it was left out.

But, its original intent was sound, and I think it could be possible to 
include a preprocessing step that doesn't allow for easy obfuscation of 
code, or crazy code block bugs (anyone remember the while(0) hack?).  I 
don't think it would be a sin at all to include a safe and modified 
subset of a C style preprocessor to D.  Although I realize that's never 
going to happen, so it's probably pointless to bother thinking about :).

Either way, as bearophile suggested, I think the AST macros should do 
the trick (I wasn't ware of them when I made my initial reply), so no 
worries.