--- Comment #6 from Tomas Lindquist Olsen <> 2012-01-27 
05:45:44 PST ---
It's been five years. TBH I don't really care anymore. Close this issue up if
you will, I've moved on ...

(In reply to comment #5)
> (In reply to comment #0)
> > /// this is a class
> > class A
> > {
> > /// This mixin will bla bla bla
> > mixin MyMixin!();
> > }
> > 
> > this will only generate docs for the class. not the mixin.
> > Some will probably consider this a feature request, but I'd call it a bug...
> I would call it a feature request, because for it to be a bug, there would 
> have
> to be a clear definition how this should work or a similar case that can act 
> as
> a template. DDoc documents 'classes', 'structs', 'methods', ... in other words
> named symbols. "mixin MyMixin;" isn't a symbol and usually not interesting for
> the user of the class. And private members aren't documented, because they
> aren't usable by the target audience of API docs. So I assume your mixin does
> not itself add public symbols that should be documented ? Or do you request a
> feature to go beyond API documentation with DDOC, and also document how a 
> mixin
> is expanded in the class ? That's what normal comments are for!
> Maybe you can elaborate a bit on what the mixin does and why it is necessary 
> to
> document the 'unexpanded' thing ? I would say yes, if you proposed to move 
> generation after mixin expansion (so newly introduced methods can be
> documented), but then you could document them inside the mixin itself - which
> would be a different 'bug'. Remember that a single mixin can add any number of
> new symbols, so documentation above "mixin ..." may come short in many
> situations. You can also discuss this on the D newsgroup, but be sure to give 
> a
> strong argument (real example code) for this feature.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to