new DIP47: Outlining member functions of aggregates

[Dicebot]

On Sunday, 8 September 2013 at 13:11:01 UTC, Gary Willoughby 
wrote:
>> That said, I am strongly against permissive rules proposed in 
>> this DIP. It should be similar to overriding rules - any 
>> smallest difference between to signatures and program stops 
>> compiling. Otherwise it is maintenance hell.
>
> Well you've just argued against your first paragraph there. The 
> issue is (as you recognise) the extra complexity introduced 
> with having a declaration and an implementation both of which 
> could be different and/or not clear how they relate.

Not really. Issue is cognitive load of matching definition and 
declaration if they are allowed to be out of sync.

> But it goes further than that. If this DIP is implemented and 
> you are working with code written like this you now have to 
> change the code in two places when you want to update a method. 
> Also you now have to find the implementation or declaration 
> which is a total pain when not using an IDE.

I consider it a minor inconvenience for a certain structural gain.

> This is entirely different to how overloading works because in 
> that scenario you are explicitly saying in your code this 
> method overrides the parent (or interface) with this one that 
> matches that signature exactly. There is no duplication, it's 
> explicit overriding which is different.

overloading != overriding. I am speaking about overriding. From 
the maintenance point of view this two snippets are identical:
---
interface A
{
     void foo();
}

class A_prim : A
{
     void foo() { }
}
---
class A
{
     void foo();
}

void A.foo()
{
}
---

Same amount of duplication, same amount of information available 
for compiler verification.

> Also could you give me any examples of where keeping the 
> declaration separate to the implementation is "sometimes/often 
> useful". Because IMHO it only adds work and Java and C# do just 
> fine.

I have never worked on any reasonably large Java/C# code base. 
But it C++ once amount of entities grows large enough clear 
interface overview in header files is basically only way to get 
familiar quickly with sources.

As I have already said it is good for same reasons interfaces are 
good - easier to abstract away information you shouldn't be aware 
of when working in large teams.

> I don't think Walter realises how much of a plus point it is 
> for D to not have this 'feature'. I mean if this was 
> implemented and code started appearing written in this style 
> (as it will) why would people choose D over C++ to get stuff 
> done when they both offer the same headaches now?

I don't think it will matter at all. As it was mentioned, usage 
of such feature tends to be private business of certain project - 
it won't propagate to yours  if you don't use it.

And you really underestimate issues of C++ that force programmers 
to seek other languages. Separation of definition and declaration 
won't probably be even in top 50.