Another use case for __traits(docComment)

Steven Schveighoffer schveiguy at gmail.com
Tue Nov 12 15:14:17 UTC 2019


On 11/12/19 1:32 AM, FeepingCreature wrote:
> On Tuesday, 12 November 2019 at 01:59:55 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 12 November 2019 at 01:22:09 UTC, Exil wrote:
>>> Someone might come around and say, why modify documentation and code? 
>>> Why not just modify documentation and then have the code read from 
>>> that documentation and change behavior instead. That way you keep 
>>> documentation and implementation in sync!
>>
>> Heh, that might actually be kinda interesting.
>>
>> But you can already do that kind of thing, just with slightly 
>> different syntax. You can put that in a UDA and process it with 
>> reflection at CT and embed it into documentation through the UDA too. 
>> (my doc generator supports pulling in UDAs to work around the lack of 
>> ddoc in reflection; I had to move docs to a UDA and now they're 
>> combined anyway, it is just hideous and not as compatible with third 
>> party things)
> 
> This is also my view. D already supports things that are this messy or 
> more. All this restriction does is lock the barn after the horse has 
> bolted.
> 
> You can already do the same degree of mess. You just have to make it 
> ugly. All this restriction does is make good, useful code worse for 
> little benefit.

Breaking the fundamental rule of "this is a comment, it doesn't affect 
code" that we all learn on day 1 of programming needs a very very 
compelling use case. I haven't seen it yet.

Alternatively, we could use something other than comments for 
documentation. e.g.:

@ddoc {
.... // documentation
}

-Steve


More information about the Digitalmars-d mailing list