Another use case for __traits(docComment)
dkorpel at gmail.com
Thu Nov 14 09:54:35 UTC 2019
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:
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
> 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);
@(fooComment) void foo(string a);
It's hard to argue what the best current solution is without a
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.
More information about the Digitalmars-d