Another use case for __traits(docComment)

Adam D. Ruppe destructionator at gmail.com
Tue Nov 12 01:29:57 UTC 2019


On Monday, 11 November 2019 at 20:15:56 UTC, Steven Schveighoffer 
wrote:
> Certainly, it could be allowed at compile-time and just be a 
> guideline not to write code that cares about the data. But we 
> all know that it will happen.

Indeed, I have seen a lot of trash D code out there.

But I don't want to remove useful features because of it.

> For instance, I like how documented unit tests simply turns the 
> unittest into a ddoc, instead of making ddoc turn into a unit 
> test (which likely could have been the solution if 
> __traits(docComment) were available back then).

I actually doubt that would have been used because that needs 
significant progressing anyway. What we did use before the 
unittest thing was just extract the code from the generated HTML 
documentation which is pretty easy too.

(that's probably what I'll do with my program here, just dump the 
comments to a separate file and then `import` it to populate the 
map. but so much more complicated and fragile than just pulling 
the comment off while reflecting anyway)

> It would be something that could potentially be expanded later 
> if needed. It's easier to let the toothpaste out of the tube 
> slowly than try to put some of it back in.

true. like I'd rather have it just for runtime processing than 
not at all, but it is still just bleh.


More information about the Digitalmars-d mailing list