Proposed improvements to the separate compilation model

[H. S. Teoh]

On Tue, Mar 05, 2013 at 06:39:07PM +0100, Rob T wrote:
> On Tuesday, 5 March 2013 at 12:01:54 UTC, eles wrote:
> >On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
> >>+1_000_000_000
> >>
> >>Yes please!
> >>It's near impossible to get a brief overview of a class at a
> >>glance in D!
> >
> >Exactly for this reason, what about make this way at least the
> >recommended way, if not the single one?
> >
> >What is to lose? As about what to win, basically each .d file will
> >carry its .di file (class definition) inside it, and the latter
> >can be easily extracted (both visually and automatically).
> >
> >Just one note: please allow that the private variables of a class
> >(those that are not exposed outside the file) be declarable
> >outside the main definition of the class, that is with the .
> >syntax. This will completely make declaration and implementation
> >independent, to the point that the class definition is an
> >interface and nothing else.
> 
> This is what I'd like to see happen with modules which seems to be
> in agreement with what you are proposing: The module source file
> should contain everything needed to automatically generate and
> maintain a .di file. There should no need to manually maintain a .di
> file.

+1.  It should be the compiler's job to export the public API of a given
.d module, not the programmer's. By default, it should export only
public members.

Optionally, we can use UDAs to override compiler defaults in certain
cases, where it's necessary. Ideally, such cases will be very rare.


> How we accomplish that goal is an implementation detail, however I
> fully agree that something needs to be done and it should be done
> without any need to manually maintain separate .di files.

+1.

Separate maintenance of header files in C/C++ has always been a pain and
source of inconsistencies. It's one thing when you have a small
dedicated team working on the same codebase; I have seen such code in
projects that were handed around to different people (due to the usual
reasons -- turnover, company reorg, etc.), and inevitably, the headers
go out of sync with the implementation files.

I've actually seen (and fixed) a case of two C functions that were
declared with the same name in two different libraries, and in one
module, the wrong library was linked in, thus linking the call to the
wrong function, causing strange runtime problems that no amount of
staring at the source code would reveal the reason for. The #include was
perfectly correct; but the problem was that the declaration was detached
from the implementation, so the compiler has no way to check for this
kind of problem.

Not to mention the silliness of having to copy-n-paste function
prototypes in two places -- in this day and age, why are we still
promoting such error-prone manual hackish ways of coding? Such things
should be automated!

D's module system is the beginning of a sane handling of such issues.
Let's not go back to the bad ole split header/implementation approach.
It should be the compiler's job to extract the public API of a module
*automatically*, so that consistency is guaranteed. No room for human
error.


T

-- 
The best compiler is between your ears. -- Michael Abrash