new DIP47: Outlining member functions of aggregates

[Joseph Rushton Wakeling]

On 09/09/13 18:41, Ettienne Gilbert wrote:
> I would argue that it is actually better this way (that not all functions need
> to be in the declarations list) - its way more flexible! This way you can leave
> out function declarations that you are not really interested to see from a
> "functional overview perspective" of the class.

AFAICS the request is for separation of declaration and definition, so you'd be 
able to do things like this:

     class Foo
     {
         void foo();
         int bar(double x);
         void goo(int n);
         // ... etc.
     }

... and then later in the same file:

     void Foo.foo()
     {
         /* ... function body ... */
     }

     int Foo.bar(double x)
     {
         /* ... ditto ... */
     }

     void Foo.goo(int n)
     {
         /* ... and so on ... */
     }

Now, you'd be at liberty to mix declarations and definitions in the _class_ (or 
struct) declaration, e.g.:

     class Foo
     {
         void foo(); // we define this somewhere else

         int bar(double x)
         {
             /* ... but we define this here */
         }

         // ... etc.
     }

But supposing that a function is declared but not defined inside the class 
declaration, it should be obligatory that it _is_ defined somewhere else in the 
file -- and conversely, if a class function is defined somewhere else in the 
file, it should be obligatory that it's declared in the class declaration.

And on top of that, it should be obligatory that the declaration and definition 
match perfectly.  (Note that for any function defined in the class declaration, 
this is automatically and unavoidably true:-)

> AFAIC the cost of implementing this would be way too high for any potential
> benefit gained from this. And, since Walter already stated that this would "no
> way be mandatory", the implications are that the compiler would need to enforce
> it once any one function is declared in the declarations list, but... not
> enforce it if no functions are declared in the list!

I am personally inclined to leave it to Walter to decide whether the cost of 
this is too much.  At the very least having this possibility seems to be in line 
with earlier plans.

> Also, leaving it flexible as it is now cannot silently break anything. Worse
> that can happen is that you may inadvertently try to implement goo() twice
> (since you may think the missing declaration imply there is no definition), but
> then the compiler will anyway complain about the duplicate definition.
>
> So I agree with Jacob Carlborg - I would also like to know why the above is not
> already sufficient...?

Because it allows a situation where you can have an incomplete list of member 
function declarations for a class or struct, and yet not know that it's 
incomplete without manual checking -- which I think fails to satisfy the needs 
Manu has identified.

We can reasonably debate whether those needs are worth addressing at all, and 
whether addressing them comes at too high a cost, but we should be clear on what 
solutions address them properly and what don't.