Proposed improvements to the separate compilation model

[so]

On Sun, 24 Jul 2011 00:54:57 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> The program prints "424344" as expected.
>
> The problem with this setup is that it's extremely fragile, in ways that  
> are undetectable during compilation or runtime. For example, just  
> swapping a and b in the implementation file makes the program print
> "08.96566e-31344". Similar issues occur if fields or methods are added  
> or removed from one file but not the other.

I am not a fun of .di files but there is no reason i can think of that the  
compiler should allow such thing. If there is a .di file for the module  
compare it to the implementation. If the implementation is different, it  
is an error. If it is intended then .di file must be generated explicitly.

> So the programmers conclude they need to define an interface for A (and  
> generally each and every hierarchy or isolated class in the project).  
> But the same problem occurs for struct, and there's no way to define  
> interfaces for structs.

I don't understand why people keep bringing this as a solution, this is D.

> Ultimately the programmers figure there's no way to keep files separate  
> without establishing a build mechanism that e.g. generates a.di from  
> a.d, compares it against the existing a.di, and complains if the two  
> aren't identical. Upon such a build failure, a senior engineer would  
> figure out what action to take.
>
> But wait, there's less. The programmers don't have the option of  
> grouping method implementations in a hierarchy by functionality (which  
> is common in visitation patterns - even dmd does so). They must define  
> one class with everything in one place, and there's no way out of that.
>
> My understanding is that the scenarios above are of no value to you, and  
> if the language would accept them you'd consider that a degradation of  
> the status quo. Given that the status quo includes a fair amount of  
> impossible to detect failures and tenuous mechanisms, I disagree. Let me  
> also play a card I wish I hadn't - I've worked on numerous large  
> projects and I can tell from direct experience that the inherent  
> problems are... well, odd. Engineers embarked on such projects need all  
> the help they could get and would be willing to explore options that  
> seem ridiculous for projects one fraction the size. Improved .di  
> generation would be of great help. Enabling other options would be even  
> better.

Interface design, separate compilation, library development are one of the  
many things C++ couldn't make better than C but took it to a new low.
And i don't get why no one else here considers these are big issues and  
just go suggest C++ ways, last two times i brought up something related to  
this there was only one response. I want to believe it is because me,  
failing to express myself :)