Another use case for __traits(docComment)

[Steven Schveighoffer]

On 11/13/19 2:30 PM, Laeeth Isharc wrote:
> On Monday, 11 November 2019 at 17:16:20 UTC, Steven Schveighoffer wrote:
>> 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.

I'm trying to save the reviewers and the maintainers. Code review 
shouldn't include reviewing stuff that isn't compiled. If you are doing 
weird imports, that's an unusual situation and requires unusual knowledge.

If you put this into traits, then it's a usual and easy tool, and now 
you have to verify comments are correctly written.

If all you want is to fetch the documentation for a function, it can be 
done in better ways.

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

For sure, it's possible already to run extra steps to have *anything* 
affect the code. You could use a preprocessor that replaces ddocs with 
UDAs for the same effect. But in that case, you are altering the input 
to the compiler, not using the compiler to build something that isn't 
normal compiler input.

Of course, you can already do such things with string imports.

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

This is more akin to mixins, not goto. Goto is actually easy to review 
(automatic rejection! /jk), you know exactly what it does.

And yes, mixins are abused. I just did some work to the diet-ng project 
to make it possible to update non-interpolated HTML and have it figured 
out at runtime[1]. The way diet imports non-D code and changes it into D 
code to mixin, it's cool, but I'd consider it an abuse, and really 
difficult to comprehend. I'm getting to the point where I just think an 
external tool is better[2].

-Steve

[1] https://github.com/rejectedsoftware/diet-ng/pull/70
[2] https://github.com/schveiguy/dietpc