DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Andrei Alexandrescu via Digitalmars-d]

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