On 12/31/2016 12:20 PM, Martin Nowak wrote:
On Saturday, 24 December 2016 at 10:54:08 UTC, Stefan Koch wrote:
If that were made more lazy, we could import half of the world with
noticing impact.
(Which espcially in std.traits, would not make that much of a
difference since every template in there depends on nearly every other
template in there)
Also the established technique of serializing precompiled AST (after
semantic3) of modules to a cache should be applicable as well.
Cross-posting from
https://github.com/dlang/DIPs/pull/51#issuecomment-269107966, b/c it
wasn't answered yet.
No worries, I'll make a pass (a rewrite, really) taking all feedback
into account.
Were any other means considered? This is proposing to add plenty of
additional annotations only to speed up compilation, but none of the
classical tools for pre-compilation were assessed.
Since D's modules don't have the header problem, even pre-compilation
and reuse of semantic3 should be possible, or not?
DIP1005 gives consideration to the speed of compilation aspect in larger
proportion than speed's importance; the first and foremost benefit of
DIP1005 is it closes the gap on dependency encapsulation, which had been
very successfully narrowed by local imports. However, the DIP will keep
the experiments and results on speed measurements because they are
relevant to it and any related methods of lazily loading of modules.
Regarding the ongoing doubts about the advantages of inline imports:
they are first and foremost a completion of the nested import feature.
As such, most, if not all, arguments against inline imports apply
equally to nested imports. Come to think of it, lazy imports vs nested
imports:
* same improvement in compilation speed? check
* no language changes? check
* no nasty bugs in the aftermath (such as the infamous
https://issues.dlang.org/show_bug.cgi?id=10378)? check
* scalable builds? check
Yet local imports are overwhelmingly superior to lazy imports because of
one thing: they localize dependencies. They introduce modularity and its
ancillary perks (fast and scalable builds, easier review and
refactoring) not by engineering, but by organically placing dependencies
spatially with their dependents. (The scope statement does the same
thing with temporal dependencies.) That the DIP does not make it clear
that it is a necessary and sufficient extension of local imports is a
problem with it.
I now am really glad we slipped local imports before the formalization
of DIPs. The feature could have been easily demeaned out of existence.
Allow me to make an appeal regarding the review of any DIP. There seems
to be a tendency of some reviewers to get attached and emotionally
invested to their opinion, to the extent they'd be hurt by being "wrong"
and would go to great lengths to argue they're "right". This has obvious
negative effects on the entire process. Please don't. There's no loss of
face to worry about. The only commitment we all should have is to the
good of the D language. If DIP1005 reaches the conclusion of its own
uselessness, I'd be the first one to write it up and close the PR.
Thanks,
Andrei
