On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu
wrote:
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
Allow me just to share a worthless outsider opinion.
I never contributed anything worthwhile and decided it was better
to just focus on JVM, .NET languages., alongside C++, as those
are the skills I get paid for, thus stop polluting D forums.
Looking from the outside, and watching what was reached from 2016
roadmap, it is clear the DIPs evaluated thus dar aren't about
fixing the library or runtime issues that prevent D's adoption at
large as a systems programming language.
Meanwhile Swift, Go and Rust have a clear roadmap how their
future is supposed to look like, and drive just in that
direction, with C++ taking all remaining good D ideas.
This DIP discussion and the latest ones about splitting the
runtime again, don't do anything to earn D any credibility it
might still have left.
