new DIP47: Outlining member functions of aggregates

[Joseph Rushton Wakeling]

On 09/09/13 05:46, Manu wrote:
> For the record, I tend to agree with the arguments of many in the 'against' camp
> *from a purist point of view*, but the problem remains, and the reason I raised
> it; this has demonstrated to me and my colleagues on a number of occasions that
> it is a consistent productivity hindrance.

For what it's worth, I think this kind of baptism-by-fire practical experience 
is very valuable, and that it's worth considering carefully even if the final 
decision is not to implement the requested feature.

Question: do you have any access to information about similar short-deadline 
programming activity using other languages (Java, C# ...) that also forbid the 
separation of declaration and definition, and how devs using those languages 
cope with that?  It might offer an alternative solution that no one here has 
thought of.

> I support this DIP, obviously, but I'd suggest perhaps a conservative
> restriction that definitions should only be allowed to appear within the same
> module as the declaration. This would seem to simplify things like mangling
> issues and access rights. In my own use case, I have no reason to spread
> definitions across files. I just want to see class outlines clearly summarised
> at the top of the file. This saves time, and time is money.

I think the conservative approach is probably correct -- the class outline and 
the function definitions should have to be in the same module, and the outline 
and definitions should match precisely.  Any mismatch (including in variable 
names)?  Compile error.  A function in the outline that isn't implemented? 
Compile error.  A function implemented that isn't in the outline?  Compile 
error.  That should greatly reduce the possibility of error caused by code 
duplication.

Then it simply becomes a question of deciding if the manual labour of writing 
separate outlines and definitions is worth it.  I guess this is probably 
somewhere where a tool really _can_ be useful, to ensure that the definitions 
and the outline stay in sync.

Writing D code in this way should probably be disapproved of in the D style 
guidelines, but with the proviso that it's there for the circumstances where it 
really is useful.