DIP 50 - AST macros

[Walter Bright]

On 11/18/2013 1:14 AM, Jacob Carlborg wrote:
> Sure, what I'm saying is that you can do stupid things with other features than
> macros.

Yes, you can write terrible code with all features.

My point is not that you can do stupid things with macros. It is that macros 
encourage this to a high degree, and in fact the flexibility that macros have 
over lazy parameters / expression templates / mixin templates are exactly those 
features that are abused to the point it is hard to see much good come from 
them. I am not making this up, this is what happens with macro systems again and 
again. I know this is a difficult position to argue from and convince people about.

D has a deliberate lack of capability in some areas because long experience 
shows that little good comes from them. Examples include lack of ability to 
overload && and ||, and lack of expression support for version statements. This 
is not because these features are hard - they're easy to implement. I've seen 
attempts to replace version statements with static if in order to get back the 
ugliness, and the result is ugly and unnecessary and damned hard to figure out 
what was actually intended and why it didn't work.

I fear that implementing these things with the idea that they'll somehow be used 
with restraint is a pipe dream and that D will degenerate into an ugly snarl 
that everyone hates, and then some D-Go will be invented that everyone will 
cheer because it won't allow such code to be written.

Case in point - again and again I see utterly wretched use of macros in C++ from 
the top level of C++ programmers who really ought to know better. Want to see a 
lovely example? Take a look at the C header files for openssl:

https://github.com/D-Programming-Deimos/openssl/tree/master/C

This is not unusual.

I try to put my money where my mouth is. If you look at older parts of dmd, 
you'll see macro abuse that I cleverly wrote. The newer bits contain fewer and 
fewer use of any macros, and I've made an ongoing effort to try and eliminate 
all of it (yebblies has campaigned to get rid of it, too, even crap I tried to 
hang on to). This has been done this without compromise on performance and 
usability and readability of the code - and I hope you'll agree that it looks 
nice without the usual rat's nest of preprocessor abuse one sees in typical C++ 
code.