Bug 9695 – Ddoc should emit enum member initializers
Status
RESOLVED
Resolution
WONTFIX
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-03-11T21:19:11Z
Last change time
2017-10-28T15:35:48Z
Keywords
ddoc, pull
Assigned to
Andrej Mitrovic
Creator
Andrej Mitrovic
Comments
Comment #0 by andrej.mitrovich — 2013-03-11T21:19:11Z
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).
Comment #1 by andrej.mitrovich — 2013-03-19T21:55:25Z
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.
Comment #3 by andrej.mitrovich — 2013-03-22T15:10:45Z
(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.
Comment #4 by andrej.mitrovich — 2013-03-22T15:17:40Z
(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.
Comment #5 by andrej.mitrovich — 2014-02-03T05:58:56Z
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.
Comment #6 by timothee.cour2 — 2017-02-10T06:10:28Z