Another use case for __traits(docComment)

Dennis dkorpel at
Wed Nov 13 15:22:23 UTC 2019

On Tuesday, 12 November 2019 at 06:32:35 UTC, FeepingCreature 
> You can already do the same degree of mess. You just have to 
> make it ugly. All this restriction does is make good, useful 
> code worse for little benefit.

And that's exactly the point: you have to make it ugly, so it 
isn't an attractive option.
Some things are ugly by design, such as __gshared, discouraging 
users from using it while still allowing it if needed.

Similarly, version() statements don't allow boolean logic, 
discouraging those annoying double negations and version formulas 
(see e.g. [1], [2]) and encouraging 'positive' identifier names 
that don't have 'no' in them. You can still make version 
spaghetti with `static if` if you want, but it won't be as 

Technically you can still do C macro shenanigans like `#define 
BEGIN {` in D by putting your module in a q{} string, doing a 
string-replace in CTFE and mixing it in.
"You just have to make it ugly".
And that's exactly why D programmers don't tend to do that.

While I do see the value in __traits(docComment) (I would use it 
myself in the same way Adam wants to use it), I do have to agree 
with Steven that it just feels to powerful.
As soon as some hacker discovers `__traits(docComment)` he will 
have the 'brilliant' idea to inspect documentation and use parts 
of it for his code generation, and it will look elegant so it 
doesn't seem wrong (unlike some convoluted 
parse(import(__FILE__)) scheme).
And then a clueless contributor will be like 'how the heck did 
running dfmt on this codebase make the unittests fail'?

UDA's use string literals, so the rules of what string you get 
are exactly clear and a formatter won't touch it. How does 
__traits(docComment) behave on these two comments:

/** Word
  *  Word


What strings do they produce?


More information about the Digitalmars-d mailing list