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

[Paulo Pinto via Digitalmars-d]

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.