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

[Joakim via Digitalmars-d]

On Tuesday, 3 January 2017 at 20:07:59 UTC, Andrei Alexandrescu 
wrote:
>> 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.

I don't need dramatic, a solid win is fine. A small 10% or less 
improvement in the speed of the import phase of compilation 
probably isn't worth it.

>> 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.

If you believe the benchmarks won't be dramatically different, I 
wonder why you think there will be a phase change.

>> 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.

Encapsulation is not an end in itself.  You have listed four main 
advantages of this change in the DIP.  I have noted that I don't 
find the first three relating to reasoning and refactoring worth 
adding syntax for, while admitting that may be subjective.  The 
fourth talks about scalability, which I interpreted as either 
compilation speed or some other measurable gain, hence my asking 
for benchmarks.

If scalability refers to something else- it can't be reasoning or 
refactoring as those are listed as separate advantages- I'd like 
to hear what it is.  If it's measurable, I'd like to measure it 
first.