proposal: private module-level import for faster compilation
Sebastien Alaiwan via Digitalmars-d
digitalmars-d at puremagic.com
Sun Jul 24 23:46:57 PDT 2016
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
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:
(though, this seems a lot like most of us already do with
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?
More information about the Digitalmars-d