I still very much want access to ddoc from reflection. In the past, these proposals have been shot down out of fears of comments affecting code.

Well, what if it was ONLY available on the declaration itself?

__traits(comment) takes no arguments and returns a string with the contents of the attached documentation comment of the current declaration. It may return null if not compiling with -D (though I think it should be available regardless, I'm open to compromise).

If the function wants to make this available to outside code, it can use it in a UDA:

struct doc {
  string text;
}

/++ comment here +/
@doc(__traits(comment))
void foo() {}

assert(__traits(getAttributes, foo) == AliasSeq!(doc("/++ comment here +/")));


Would this be more amenable to people against this in the past? Since it is tightly scoped and opt in, there'd be very little room for abuse - it just basically copy/pastes the string to a UDA for you to reuse existing language mechanisms.

On Saturday, 30 May 2020 at 23:04:42 UTC, Adam D. Ruppe wrote:
> I still very much want access to ddoc from reflection. In the past, these proposals have been shot down out of fears of comments affecting code.
>
> Well, what if it was ONLY available on the declaration itself?
>
> __traits(comment) takes no arguments and returns a string with the contents of the attached documentation comment of the current declaration. It may return null if not compiling with -D (though I think it should be available regardless, I'm open to compromise).
>
> If the function wants to make this available to outside code, it can use it in a UDA:
>
> struct doc {
>   string text;
> }
>
> /++ comment here +/
> @doc(__traits(comment))
> void foo() {}
>
> assert(__traits(getAttributes, foo) == AliasSeq!(doc("/++ comment here +/")));
>
>
> Would this be more amenable to people against this in the past? Since it is tightly scoped and opt in, there'd be very little room for abuse - it just basically copy/pastes the string to a UDA for you to reuse existing language mechanisms.

There's only one person's opinion that really matters. If you want this feature in, then write a DIP for it.

This is a pointless restriction, you can still access the string by grabbing the UDA from basically anywhere. It just makes it more obfuscated what is happening.

On Sunday, 31 May 2020 at 01:53:56 UTC, Avrina wrote:
> This is a pointless restriction, you can still access the string by grabbing the UDA from basically anywhere. It just makes it more obfuscated what is happening.

The point here is to explicitly bridge the doc comment into a UDA specifically so you can grab it from anywhere.

The author could also just copy/paste the string into two different locations (that's probably what I'll do for my immediate need btw). Just that seems silly when the author is explicitly trying to bridge these two worlds and the compiler can help with minimum chance for surprise.

That's the key difference between this and the previous proposal we had to solve this same problem: before, people were concerned that a user would depend on a comment that the author has no clue about. Here, the author is virtually copy/pasting it so there's no surprise on either end.