Another use case for __traits(docComment)

[Dennis]

On Thursday, 14 November 2019 at 05:03:49 UTC, Jab wrote:
> 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.

I just said that every feature has (hidden) cost, not that that 
cost is never justified.

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

That's not the point, the point is that it always starts with 
"but I just want X, nothing more!", and later inevitably someone 
wants Y too. Concretely in that case: "It can live peacefully 
beside your preferred design with the scopes." followed by the PR 
to deprecate extern(C++, identifier).

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

I actually think that got merged too quickly without thinking all 
special cases and consequences through.

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

Whatever you call it, it's another source of complexity as I 
mentioned before.

> How would you duplicate this doc:
>
> /// ditto

Put the UDA string in an enum?
```
enum string fooComment = "does foo"
/// does foo
@(fooComment) void foo(int a);
/// ditto
@(fooComment) void foo(string a);
```

It's hard to argue what the best current solution is without a 
concrete usecase.
If you write some functions / fields yourself, you can write some 
UDA strings that may be redundant with your doc comments.
If you want to expose documentation from an existing library 
(e.g. Phobos), it can be extracted beforehand instead.