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