• Adam D. Ruppe (23/23) May 30 2020 I still very much want access to ddoc from reflection. In the
• Avrina (6/29) May 30 2020 There's only one person's opinion that really matters. If you
• Adam D. Ruppe (13/16) May 30 2020 The point here is to explicitly bridge the doc comment into a UDA

Adam D. Ruppe <destructionator gmail.com> writes:

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.

Avrina <avrina12309412342 gmail.com> writes:

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.

Adam D. Ruppe <destructionator gmail.com> writes:

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.