Another use case for __traits(docComment)

[Dennis]

On Wednesday, 13 November 2019 at 18:46:43 UTC, Adam D. Ruppe 
wrote:
> That's because HTML ignores extra spaces.

Of course, but the overall point I'm trying to make is that the 
trait is non-trivial and adds language complexity.

It gets implemented one way, and then someone comes around 
wanting it to be different. "please give me the html instead of 
raw comment, parsing it with CTFE is slow and cumbersome"
"please include the /** or /++, I'm using __traits(docComment) to 
statically assert my preferred documentation code style"
"is it a bug that leading/trailing whitespace is/isn't trimmed?"
"the previous changes broke my existing CTFE documentation parser"
"__traits(docComment) does not work when the comment is in a 
mixin that is seen later in semantic analysis"
"I want only my doc comment of my function to depend on the build 
type, but putting the comment inside version blocks does not 
work! How to fix?"

This can of worms can stay closed by just sticking with good old 
predictable and flexible UDA strings.