Proposed improvements to the separate compilation model

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Jul 22 15:06:19 PDT 2011


A chat in IRC revealed a couple of possible improvements to the 
development scenario in which the interface file (.di) is managed 
manually and separately from the implementation file (.d).

After discussing a few ideas with Walter, the following language 
improvement came about. Consider a very simple scenario in which we have 
files a.d, a.di, and client.d, all situated in the same directory, with 
the following contents:

// a.di
class A { private int x; int foo(); }

// a.d
import a;
int A.foo() { return x + 1; }

// client.d
import a;
void main() { (new A).foo(); }

To compile:

dmd -c a.d
dmd -c client.d
dmd client.o a.o

Currently, in order for a program with separately-implemented methods to 
work properly, there must be TWO different files for the same class, and 
the .di file and the .d file MUST specify the same exact field layout. 
Ironically, the .d file is forbidden from including the .di file, which 
makes any checks and balances impossible. Any change in the layout (e.g. 
swapping, inserting, or removing fields) is undetectable and has 
undefined behavior.

I see this as a source of problems going forward, and I propose the 
following changes to the language:

1. The compiler shall accept method definitions outside a class.

2. A method cannot be implemented unless it was declared with the same 
signature in the class definition.

Walter is reluctantly on board with a change in this direction, with the 
note that he'd just recommend interfaces for this kind of separation. My 
stance in this matter is that we shouldn't constrain without necessity 
the ability of programmers to organize the physical design of their 
large projects.

Please discuss here. I should mention that Walter has his hands too full 
to embark on this, so implementation should be approached by one of our 
other dmd contributors (after of course there's a shared view on the 
design).


Andrei


More information about the Digitalmars-d mailing list