Proposed improvements to the separate compilation model

[Steven Schveighoffer]

On Fri, 22 Jul 2011 18:06:19 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

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

I have mixed feelings on this proposal.

On one hand, one of the best parts of D over C++ is it's module system.   
No more #ifdef __thisfile_included crap, and implementations just sit  
right where they are defined.  My concern with such an improvement is that  
it would encourage people (especially C++ coders) to unnecessarily split  
their implementation from the definition.  I think there have been at  
least 2 or 3 people ask how to do this in D.  I really like that  
implementation and definition are all in one file, and cannot be out of  
sync (a common problem with C++).  Already di files allow for these  
problems to creep back in, but I understand it's a necessary evil.

On the other hand, the duplication of definitions and functions for  
inlining when you do want to use .di files is a real problem, and this  
would seem to address it.  And as you point out, it doesn't eliminate the  
existing solution.

Plus, D does not suffer from multiple-personality syndrome like C++ can.   
For example, including a file more than once with different macro  
definitions to alter the impact of the include file.

As a criticism though, I don't really like this:

module std.foo;
import std.foo; // huh?

I know we don't want to add too much to the syntax, but can we make that  
line a bit more descriptive?  and also less redundant?  Suggestion:

module std.foo;
import interface; // imports the .di file that corresponds to std.foo.

I know that's keyword abuse, but it's kind of accurate ;)

-Steve