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
> 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