Another use case for __traits(docComment)

[Laeeth Isharc]

On Monday, 11 November 2019 at 17:16:20 UTC, Steven Schveighoffer 
wrote:
> On 11/8/19 9:00 AM, Adam D. Ruppe wrote:
>> Writing code to wrap some Phobos functions for a script 
>> language and need documentation to be displayed at runtime...
>> 
>> Would be really nice to just say if(other_docs.length == 0) 
>> return __traits(docComment, item).
>> 
>> A UDA can populate other_docs in some functions, but when 
>> wrapping libraries you can't add that. Having the doc comment 
>> available through reflection means we can reuse these existing 
>> items.
>
> I still am very VERY leery of having anything in comments 
> affect the code in any way.
>
> What about a compromise? Provide access to the docs but ONLY at 
> runtime. That is, you will not know anything about the string 
> at compiletime, just at runtime, and you can make your 
> decisions there.
>
> Should work for your use case.
>
> -Steve

Compiler flag as we do with string imports?  Most projects won't 
use this feature.  If it does end up being used then at least it 
will be clear.  It's difficult to save people from themselves 
completely - and I think there are many more likely ways to end 
up abusing the powerful features of D.

Suppose in scenario 1 you use doc comment traits and in scenario 
2 you have an extra build stage to achieve the same effect; and 
suppose through unfortunate choices the documentation ends up 
affecting the runtime behaviour of the code in non-documentation 
related ways.  Are you better off in scenario 1 or 2?  It's not 
clear, but 1 might be better.

D has goto - people don't habitually abuse it.