proposal: private module-level import for faster compilation

[Sebastien Alaiwan via Digitalmars-d]

On Sunday, 24 July 2016 at 15:33:04 UTC, Chris Wright wrote:
> Look at std.algorithm. Tons of methods, and I imported it just 
> for `canFind` and `sort`.
>
> Look at std.datetime. It imports eight or ten different 
> modules, and it needs every one of those for something or 
> other. Should we split it into a different module for each 
> type, one for formatting, one for parsing, one for fetching the 
> current time, etc? Because that's what we would have to do to 
> work around the problem in user code.
>
> That would be terribly inconvenient and would just waste 
> everyone's time.

I agree with you, but I think you got me wrong.

Modules like std.algorithm (and nearly every other, in any 
standard library) have very low cohesion. As you said, most of 
the time, the whole module gets imported, although only 1% of it 
is going to be used.

(selective imports such as "import std.algorithm : canFind;" help 
you reduce namespace pollution, but not dependencies, because a 
change in the imported module could, for example, change symbol 
names.)

I guess low cohesion is OK for standard libraries, because 
splitting this into lots of files would result in long import 
lists on the user side, e.g:

import std.algorithm.canFind;
import std.algorithm.sort;
import std.algorithm.splitter;

(though, this seems a lot like most of us already do with 
selective imports).

But my point wasn't about the extra compilation time resulting 
from the unwanted import of 99% of std.algorithm.

My point is about the recompilation frequency of *your* modules, 
due to changes in one module.

Although std.algorithm has low cohesion, it never changes 
(upgrading one's compiler doesn't count, as everything needs to 
be recompiled anyway).

However, if your project has a "utils.d" composed of mostly 
unrelated functions, that is imported by almost every module in 
your project, and that is frequently changed, then I believe you 
have a design issue.

Any compiler is going to have a very hard time trying to avoid 
recompiling modules which only imported something in the 99% of 
utils.d which wasn't modified (and, by the way, it's not 
compatible with the separate compilation model).

Do you think I'm missing something here?