Example: module test; /** */ enum E : char { /** */ one = '1', /** */ two = '2', } $ dmd -D -o- test.d The initializers are not present, but for documentation purposes they really should be. The question is whether to do it for all initializers, or only for user-provided initializers (if that's even possible to do at the ddoc generation stage).
https://github.com/D-Programming-Language/dmd/pull/1771
I don't see the rationale for why the initializers must be present in Ddoc. I think that violates the principle of hiding implementation details.
(In reply to comment #2) > I don't see the rationale for why the initializers must be present in Ddoc. I > think that violates the principle of hiding implementation details. This only applies to documented members. Anyway I'll bring this up in the newsgroups to see if it's wanted by other people.
(In reply to comment #2) > I don't see the rationale for why the initializers must be present in Ddoc. I > think that violates the principle of hiding implementation details. I've got an idea: How about we emit the initializer inside a new macro (say MEMBERINIT), which by default is set to output nothing. Then a user could override this in his own .ddoc file to emit the initializer.
Marking as WONTFIX, although for JSON we'll probably have to introduce initializers to the output to allow DTOH to emit proper C++ header code.
This causes issues because of https://issues.dlang.org/show_bug.cgi?id=129 (DDoc downgrades enum to their integer initializers); I also discuss this in https://issues.dlang.org/show_bug.cgi?id=17171
Returning to WONTFIX status. See issue 9695 comment 6 for rationale.