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

[Andrei Alexandrescu via Digitalmars-d]

On 01/03/2017 03:10 AM, Joakim wrote:
> On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu wrote:
>> 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.
>
> Except that almost nobody has argued against local imports.

I don't have time to research this, but my recollection is that at least 
some framed the bugs regarding lookups as a fundamental problem of local 
imports, not a simple matter of getting it right.

Overall, yes, local imports have been a success (really saving 
scalability of large project builds which looked pretty bleak at a 
time), which should increase trust in the authors of the feature... 
hmmm... :o)

> Rather, the
> argument is that local imports mostly solved this problem, so why bother
> adding new syntax for the dozen remaining symbols from 2-3 modules that
> are commonly used in template constraints?

I understand. It is my humble opinion that we are "mostly pregnant" for 
as long as we require top-level imports. The real change of phase occurs 
when there are ZERO imports at top level. That's the prize DIP1005 is after.

> Arguing that local imports have been successful so we should simply do
> more of it is not a good argument, as there comes a point of diminishing
> returns.  You need to show that there are still worthile gains to be
> made from changing the language again, which is why I want to benchmark
> this feature with Walter before deciding.

You can be reasonably certain the benchmarks will improve as projected - 
starting in proportion to the the transitive fanout of top-level imports 
(10.5x for the standard library) and going down thereafter with the 
size, complexity, and actual dependencies of the module being compiled. 
All in all measurable but not dramatic. The same improvement will be 
brought about by lazy imports, and it won't be the deal maker/breaker. 
If you're waiting for the numbers to get convinced of anything, you 
already consider DIP1005 useless.

>> 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.
>
> We could level this analysis back at you: you consider this DIP so
> "obvious" that you are not engaging with our concerns, making flip,
> incorrect remarks about how we would have bikeshedded local imports also.

I apologize it my remarks seem flippant, though I honestly have 
difficulty finding evidence of that. All I did was note that many of the 
arguments pitching lazy imports as a better solution than DIP1005 
(except of course for the Amdahl one) apply directly to local imports.

> In the end, this is a minor DIP that is easily bikeshedded, as everybody
> can grasp it and have an opinion on it.  I have refrained from
> commenting recently because I will let benchmarking settle it for me.
> Obviously, that won't suffice for others.

I do agree that if framed as a modest improvement in build economics, it 
is quite unimportant. But that's a problem with the DIP; its main 
strength is better encapsulation, which is no small thing.


Andrei