new DIP47: Outlining member functions of aggregates

[Andrei Alexandrescu]

On 9/8/13 5:33 AM, Andrej Mitrovic wrote:
> On 9/8/13, Michel Fortin <michel.fortin at michelf.ca> wrote:
>> So I'd like to suggest this: allow a .d file to "import" its corresponding
>> .di file.
>
> This is actually what Andrei proposed as well.

I have to say I was a lot more in favor of the proposal before this thread.

The problem as I see it has two facets:

1. Code duplication

2. Modularity and logistics

Regarding (1), we currently force duplication of the entire class 
layout. My understanding is that this is the way it's done:

// file acme.di

class A {
   int x;
   double y;
   void fun();
}

// file acme.d
// cannot import acme.di
class A {
   int x;
   double y;
   void fun() { ... }
}

The fact that acme.d cannot import acme.di is an unforced error of 
embarrassing proportions and consequence. That should be fixed yesterday 
no matter how we proceed otherwise.

The problem with acme.d not having access to acme.di is that any error 
in duplicating the layout of A (e.g. swapping x and y or adding some 
other members etc) will have undefined behavior, and there is no 
reasonable way for the compiler to check against that.

Assuming that bug is fixed, the problem of duplication remains - all 
state of the class must be duplicated.

(I also suspect constructors might need to be white-boxed (i.e. 
available in the .di) for raw/cooked typechecking, but I'm not sure.)

If we go with DIP47, the duplication of state goes away. However we have 
a distinct problem - modularity, which segues into (2).

Allowing out-of-module implementations of individual methods poses 
additional modularity problems. Consider:

// file acme.di

class A {
   int x;
   double y;
   void fun();
}
private int a;
private void gun();

// file acme.d
// assume we solve the import problem
import acme;
void A.fun() { gun(); a = 42; }

If A.fun() were defined inside acme.di, it would have access to gun() 
and a. Defining it outside asks the question - do we allow such access, 
or not?

Intuitively the body of a method should not be all too sensitive to 
where it's placed, so that argues in favor of visibility.

D's module system has always favored a file-granular approach, e.g. 
private stuff is module-private. This notion of spilling private access 
outside the file into methods defined in various other files works 
against that nice tenet.

So it looks there's no obvious and obviously good solution. Probably the 
first one is more sensible.


Andrei