Another use case for __traits(docComment)

[Adam D. Ruppe]

On Wednesday, 13 November 2019 at 19:15:56 UTC, Dennis wrote:
> Of course, but the overall point I'm trying to make is that the 
> trait is non-trivial and adds language complexity.

It doesn't have to be. All I want is the existing string.

The ONLY addition I am calling for is that a trait docComment (or 
whatever) returns the ddoc string attached to the declaration 
(and if the existing implementation strips delimiters, so be it, 
and if not, so be it, the spec does define stripping them so i 
assume it does but I don't really care).

Everything else is already defined or out of scope, so we really 
shouldn't be worrying about them.

> It gets implemented one way, and then someone comes around 
> wanting it to be different. "please give me the html instead of 
> raw comment

Impossible, since that's undefined.

> "is it a bug that leading/trailing whitespace is/isn't trimmed?"

Clear answer to this: no, it is not a bug. That's defined to be 
there.

> "the previous changes broke my existing CTFE documentation 
> parser"

ddoc is part of the spec and it has had breaking changes, we just 
deal with it.

> "__traits(docComment) does not work when the comment is in a 
> mixin that is seen later in semantic analysis"

This is similarly already an open question with the language. 
Should __traits(allMembers) return stuff from mixins?

> "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 is also already well-defined, version applies to 
declarations, doc comments are part of a declaration, not a 
separate entity.