On 09/09/13 20:05, Jesse Phillips wrote:
> I think DDOC should be improved to handle this scenario. Being able to generate
> docs with undocumented members would be great for internal development of the
> module. I realize that doesn't address all your problems, but I think that is
> the correct direction.

Better DDoc is always going to be nice, but come on -- that doesn't address the issue of looking at code in a diff or a copy-paste via chat software, and in the scenarios Manu has described, no one's going to have time to write documentation comments.

OK, you could have a DDoc setting to at least _list_ all elements of class interfaces etc., even if there's no doc comment, but that doesn't address the other factors.

On Monday, 9 September 2013 at 18:23:21 UTC, Joseph Rushton Wakeling wrote:
> Better DDoc is always going to be nice, but come on -- that doesn't address the issue of looking at code in a diff or a copy-paste via chat software, and in the scenarios Manu has described, no one's going to have time to write documentation comments.

This is such a poor argument for changing and further complicating the language. There are so many ways to get a class overview *even* in plain text. I can't honestly believe this is the catalyst for this DIP.

On 09/09/13 20:30, Gary Willoughby wrote:
> This is such a poor argument for changing and further complicating the language.
> There are so many ways to get a class overview *even* in plain text. I can't
> honestly believe this is the catalyst for this DIP.

I can understand anyone feeling that the costs aren't worth it, but I don't think it's ever good to dismiss battle experience of skilled developers, especially when it comes from scenarios that you or I may not have personal experience of.

I don't mind finding out I'm wrong (actually, I'd quite like to be in this case:-), but I'd like to understand how I could get the class overview in the plain-text scenarios described in my previous email.

On Monday, September 09, 2013 15:51:11 Joseph Rushton Wakeling wrote:
> On 09/09/13 15:12, Daniel Murphy wrote:
> > "Jacob Carlborg" <doob@me.com> wrote in message news:l0jrm7$3199$1@digitalmars.com...
> > 
> >> So what's wrong with this approach, that's already working today:
> >> 
> >> class Foo
> >> {
> >> 
> >> void foo ();
> >> 
> >> void foo ()
> >> {
> >> 
> >> }
> >> 
> >> }
> >> 
> >> void main ()
> >> {
> >> 
> >> auto foo = new Foo;
> >> foo.foo();
> >> 
> >> }
> >> 
> >> BTW, this feature was implemented because you asked for it.
> >> 
> >> --
> >> /Jacob Carlborg
> > 
> > Whoa, I didn't think of applying that to member functions. This seems
> > like
> > the answer. Put your variables and function prototypes at the top of your
> > class. Done.
> 
> Problem -- what about:
> 
> class Foo
> {
> // Declarations
> void foo();
> int bar(double n);
> 
> // Definitions
> void foo() { .... }
> int bar(double n) { ....}
> 
> // Whoops! Forgot to include this one in the
> // declarations list, but it's still accepted
> // as part of the class
> void goo() { ... }
> }
> 
> A well-defined rule for separating out declarations and definitions would check for that and throw a compile error.

Walter's proposal would be no different on that count. All that the DIP is proposing is a way to define a member function outside of a class. That requires that it already be declared in the class, but it doesn't make it so that you can't define other functions directly in the class.

- Jonathan M Davis

On Mon, Sep 09, 2013 at 08:23:07PM +0200, Joseph Rushton Wakeling wrote:
> On 09/09/13 20:05, Jesse Phillips wrote:
> >I think DDOC should be improved to handle this scenario. Being able to generate docs with undocumented members would be great for internal development of the module. I realize that doesn't address all your problems, but I think that is the correct direction.
> 
> Better DDoc is always going to be nice, but come on -- that doesn't address the issue of looking at code in a diff or a copy-paste via chat software, and in the scenarios Manu has described, no one's going to have time to write documentation comments.
> 
> OK, you could have a DDoc setting to at least _list_ all elements of class interfaces etc., even if there's no doc comment, but that doesn't address the other factors.

Auto-generation of .di files solves this problem. (Provided we fix the mess that is the current implementation of .di generation, of course.)


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.

On 09/09/13 21:30, Jonathan M Davis wrote:
> Walter's proposal would be no different on that count. All that the DIP is
> proposing is a way to define a member function outside of a class. That
> requires that it already be declared in the class, but it doesn't make it so
> that you can't define other functions directly in the class.

Sure.  The thing is that if you can only declare and define within the class, this potential problem is unavoidable -- you can _never_ be certain that your list of declarations is complete.

If on the other hand you can define outside the class declaration, then you can make it a design decision to only declare within the class declaration, and to define elsewhere in the module.  In that case it should be possible to guarantee a safety check that what's declared is defined and what's defined is declared -- and that the two match precisely.

On 9/9/13, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> A well-defined rule for separating out declarations and definitions would
> check
> for that and throw a compile error.

You could use compile-time introspection where the API would look like:

class C
{
    void foo();
    void foo() { }
    void bar() { }  // missing declaration
    mixin VerifyDeclarations;
}

And this would statically assert if there's a missing declaration for a definition. I think this might even be doable with the current introspection features, although I'm not sure whether we have a way to determine if something is a declaration or a definition. Certainly such a trait could easily be added to the compiler.

On 09/09/13 22:01, Andrej Mitrovic wrote:
> You could use compile-time introspection where the API would look like:
>
> class C
> {
>      void foo();
>      void foo() { }
>      void bar() { }  // missing declaration
>      mixin VerifyDeclarations;
> }
>
> And this would statically assert if there's a missing declaration for
> a definition. I think this might even be doable with the current
> introspection features, although I'm not sure whether we have a way to
> determine if something is a declaration or a definition. Certainly
> such a trait could easily be added to the compiler.

Fair enough.  In that case I guess my objections don't really hold water.

On 9/9/13 12:35 PM, H. S. Teoh wrote:
> Auto-generation of .di files solves this problem. (Provided we fix the
> mess that is the current implementation of .di generation, of course.)

OK, so what's the trouble with .di generation today?

Andrei

On Monday, 9 September 2013 at 21:20:34 UTC, Andrei Alexandrescu wrote:
> On 9/9/13 12:35 PM, H. S. Teoh wrote:
>> Auto-generation of .di files solves this problem. (Provided we fix the
>> mess that is the current implementation of .di generation, of course.)
>
> OK, so what's the trouble with .di generation today?
>
> Andrei

Related to this: Is semantic information necessary for .di generation, or can it be built from the AST?