Proposal: __traits(getComment, symbol)
Mike Franklin
slavo5150 at yahoo.com
Wed Aug 28 09:44:10 UTC 2019
On Wednesday, 28 August 2019 at 08:51:24 UTC, FeepingCreature
wrote:
> I propose a way to get the comment on a symbol at compile time.
> I believe this was already rejected, though I don't know why;
> I'd expect it to be something like "code should not change
> behavior due to a comment." I think that now that we have
> user-defined annotations there is a much lower risk of that.
>
> Why do I want this? Generating special documentation/annotated
> interfaces from D code is a *lot* easier if you can get the
> compiler to do your introspection work for you. I want to
> generate Swagger files documenting our REST services, and I
> want to use D comments to document them. Right now, I will have
> to do a weird hybrid dance where I generate the D type graph on
> the D side with compiletime introspection, output it to a file,
> simultaneously generate the Ddoc JSON file with -D -X to fish
> out the comments, then fuse the two together. There is no need
> for this, but for the absence of __traits(getComment).
In general, I'm in favor of adding any compiler information to
the `__traits` system. This one is particularly interesting
though.
I once gave a talk at DConf explaining how I copy and pasted
register table from a datasheet into an application, and had it
spit out D code. I later ported the code to D
(https://github.com/JinShil/stm32_datasheet_to_d). With your
proposal, I could just paste the text from the datasheet into my
DDoc comment and have D generate the code for me. Chuckle,
Chuckle.
Now think what people more "creative" than I could come up with.
:-)
I'm not sure if it would be good practice.
Mike
More information about the Digitalmars-d
mailing list