new DIP47: Outlining member functions of aggregates

[Ettienne Gilbert]

On Monday, 9 September 2013 at 13:51:20 UTC, Joseph Rushton 
Wakeling wrote:
> On 09/09/13 15:12, Daniel Murphy wrote:
[snip]
>>> /
>>
>> 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.

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.

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!

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...?