Another use case for __traits(docComment)

[Jab]

On Wednesday, 13 November 2019 at 20:38:07 UTC, Dennis wrote:
> On Wednesday, 13 November 2019 at 19:44:38 UTC, Adam D. Ruppe 
> wrote:
>> The ONLY addition I am calling for is that a trait docComment 
>> (or whatever) returns the ddoc string attached to the 
>> declaration
>
> That may be the only thing _you_ want, but then someone else 
> comes along who wants something different.
> All Manu wanted was a mangle-only `extern(C++, "ns")` as an 
> additional option, so simple. Why was Walter initially so 
> resistant for such a harmless addition? Then it got merged.
>
> https://github.com/dlang/dmd/pull/8667
>
> Then the issues come in.
>
> https://issues.dlang.org/show_bug.cgi?id=19278
> https://issues.dlang.org/show_bug.cgi?id=19339
> https://issues.dlang.org/show_bug.cgi?id=19557
> https://issues.dlang.org/show_bug.cgi?id=19574
> https://issues.dlang.org/show_bug.cgi?id=19893
> https://issues.dlang.org/show_bug.cgi?id=19920

IIRC there was a WIP pull request accompanied by a DIP, the pull 
request was merged while it was still being ironed out along with 
the DIP. Those were all easy fixes foir the most part. Hell 
there's still bugs being fixed regarding extern(C). With that 
kind of justification no new features should ever be added. Not 
to mention bug fixes that just cause no bugs. We should just stop 
making changes all together. Point to one of D's biggest 
mistakes, even then I would still say that's not a good enough 
reason to not make changes.

> And someone wants to deprecate the old way.
>
> https://github.com/dlang/dmd/pull/10031


They probably want to, because the old way is impeding the new 
method, you can't use CTFE to construct a string.


> I'm not saying it wasn't worth it in that case, but those 
> fictional remarks about __traits(docComment) were supposed to 
> show that the trait will be ANOTHER source of enhancement 
> requests, introduces ANOTHER thing that can get queried during 
> any point of semantic analysis, probably making it ANOTHER 
> source of DMD bugs, and it will be ANOTHER source of confusion 
> / material for D learners to swallow.
>
> That's just how it goes despite how simple it may look, and the 
> question is whether the new trait justifies this cost. Not 
> every code annoyance warrants a new feature, sometimes it's 
> better to e.g. duplicate a few lines of code instead of 
> introducing another C-macro.

Here's a counter example to your example: 
https://github.com/dlang/dmd/pull/10013

I wouldn't really say it's a new "feature". It'd just be exposing 
the information that is already available


> Likewise, in this case having some duplication in UDA's or

It's not just duplication, you'd have to modifying other people's 
source code. How would you duplicate this doc:

/// ditto

The implementation then becomes much more convoluted.

> having another build step may be the easier solution in the end.

Using dub? That's going to be a pain in the ass honestly. This 
sort of implementation you'd have to do isn't that simple. You'd 
have to effectively run a dub command twice, once to generate the 
doc output and then run it again to compile the code with the now 
available documentation. Dub wasn't designed for that, and build 
systems for C/C++ are often overly complicated because the 
languages don't expose information that the compiler already has 
available to it. Basically of what D does right with it's compile 
time features. __traits already has an atrocious eye catching 
name. If you need to find code somewhere that might be doing 
something with comments that it shouldn't be doing, it's not 
going to be that difficult to find.