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