Another use case for __traits(docComment)
laeeth at kaleidic.io
Wed Nov 13 19:30:16 UTC 2019
On Monday, 11 November 2019 at 17:16:20 UTC, Steven Schveighoffer
> 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
> 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.
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.
More information about the Digitalmars-d