new DIP47: Outlining member functions of aggregates

[Joseph Rushton Wakeling]

On 09/09/13 23:45, Ettienne Gilbert wrote:
> Ahh, ok. I see where you are coming from - you were evaluating the implications
> of what Jacob Carlborg proposed if "mixed" in with Walter's DIP47, right?

The code that Jacob proposed is currently legit D code and that isn't going to 
change -- and if that solution works for you (or other people), great.  However, 
I don't think it completely address the requirements the DIP is attempting to 
meet.  In my previous email I was simply trying to show that implementing new 
functionality to allow class functions to be defined outside the class 
declaration, wouldn't be incompatible with writing code like Jacob's (although I 
don't see why anyone would mix the approaches in this way).

In terms of where I'm coming from, it's more in line with Dicebot -- I think 
both of us have been focused on the simultaneous usefulness and necessity of 
being able to check declaration against definition for class member functions 
that are declared and defined separately.

> If you mix the 2 I agree with you for the most part. But the real question for
> me (and I suspect Jacob) is this:
>
> Is this...
>
>>  [ ... snip code ...]
>
> ...really so much better than this?
>
>>  [ ... snip again ...]
>
> Granted, this sacrifices some flexibility from DIP47. But these are of such
> dubious quality/use/potential pitfalls (as discussed in this thread), that I
> hardly think DIP47 is worth implementing as a result. Especially since, what we
> currently have (as shown by Carl,) already gives you arguably 90%+ (IMHO) of
> Manu's request for (I quote) "You don't need to see the function bodies in the
> class definition, you want to quickly see what a class has and does". Does it
> really matter that the function definitions are also present inside the class
> definition, as long as you can also see "what a class has and does" in the
> declarations list at the top?

The point is about being able to check that your declaration list has a 
one-to-one match with your definition list.  If you just decide to place 
declarations at the top of the class definition, and definitions lower down, you 
run the risk of accidentally missing one of the defined functions out of the 
declaration list:

     class Foo
     {
         // Declarations
         void foo();
         void bar();

         // Definitions
         void foo() { ... }
         void bar() { ... }
         void goo() { ... }  // Whoops!  This is part of the class API but
                             // we forgot to include it in our declaration
                             // list ...
     }

But Andrej Mitrovic has suggested a means to implement those kind of 
introspective checks at compile-time, so maybe it's not as urgent as I first 
thought.  (My one caveat is that I think solutions based on programmer virtue, 
like remembering to insert a line: "mixin VerifyDeclarations;" into a class, are 
generally less nice than solutions where the compiler does your checking for you 
without you having to ask.)

> Of course fixing the current issues with .di generation is important as a
> separate issue.

Yes, absolutely.