My Meeting C++ Keynote video is now available

Jacob Carlborg doob at
Wed Jan 16 10:23:11 UTC 2019

On 2019-01-16 06:32, Walter Bright wrote:

> You deliberately wrote that, and I'm confident you'd never try to pass 
> that off as good work.

Yes. I'm showing it's possible to write bad code in all programming 
languages with all (most) features. Macros are not required for that.

> With macros, however, programmers are convinced they are creating models 
> of clarity. I've seen programmers truly believe:
>      #define BEGIN {
>      #define END }
> improves their C code. Fortunately, that was ridiculed out of existence 
> in the 1980s, but the more subtle abuses persist with their ardent 
> defenders. I used to use a lot of macros in my C code, and a few years 
> back made an effort to remove them all from the dmd source code. The 
> result was very satisfactory.
> I've seen entire code bases abandoned because of macros after the 
> original developer left.

D has done a great job of replacing the C preprocessor with alternative 
features. These include: "import", "debug" and "version". These features 
are great and don't need much improvement. They take care of the stuff 
that is really difficult to avoid the preprocessor in C for.

Then we have the other stuff: macros. To insert code at the 
instantiation point. For this, D has string mixins and template mixins. 
This is where D is lacking some features. For example, it's not possible 
to insert a symbol with a string mixin that the surrounding scope at the 
instantiation point cannot access. For example, you want to insert two 
symbols, but the surrounding code should only have access to one of the 
symbols, the other one is a helper symbol to the first one. This is not 
possible today. Unfortunately that doesn't stop anyone from trying to 
come up with there own workarounds and solutions, like generating some 
obfuscated symbol name. It's not gonna make it less accessible, just 
less likely to collide with an existing symbol.

It's also not possible to insert a symbol that refers to another symbol 
in another module without risking a symbol conflict in the local scope.

There's a word for this, mixins are not hygienic.

While D improves a lot on the C preprocessor it didn't reach all the way 
to cross the finish line.

/Jacob Carlborg

More information about the Digitalmars-d-announce mailing list