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

[Chris Wright via Digitalmars-d]

On Fri, 23 Dec 2016 23:41:46 -0500, Andrei Alexandrescu wrote:

> On 12/23/16 9:23 PM, Chris Wright wrote:
>> The comparison to mach.d is a strawman.
> 
> The mach.d is given as an example of the approach of breaking code into
> fine-grained module. No comparison is made or implied.

"Assuming module size is a project invariant, the number of files scales 
roughly with project size. This means mach.d would need 2000 files to 
scale up to the same size as the D standard library"

That's a direct comparison that you made. You might want to remove that 
from the proposal if you don't want to compare them.

> Could you please give more detail about the method you used?

An insufficient one.

(I would think this sort of analysis would generally be the burden of the 
proposer, generally.)

https://gist.github.com/dhasenan/681b5178672556aa0e5ec8fb4c9eae7e uses 
dmd's json output instead of regular expressions and should be rather 
better.

This shows a total of 35 templates used in template constraints, 124 
usages in total.

The quick usage breakdown:

 1 std.experimental.ndslice.internal
 1 std.experimental.ndslice.slice
24 std.meta
31 std.range.primitives
66 std.traits
 1 std.typecons

Notable mentions: the ndslice templates are used only in other ndslice 
modules, and the std.typecons reference is from 
std.experimental.typecons. So it's still ~10ms of overhead, by both our 
measurements.

> And again the
> feature's benefits go well beyond making general projects faster to
> build.

You may as well remove the parts about compilation efficiency from the 
proposal entirely, then.

The DIP's points here aren't invalid. However, static and selective 
imports work nearly as well. A doc generator that turns referenced 
identifiers into links (like dpldocs.info) works nearly as well for 
reading. For moving files between modules, that's relatively rare, and 
fixing imports is a small part of it. (In the worst case, I can copy all 
imports over and use dustmite to reduce them. Or just leave them.)

It provides small occasional benefits for a nontrivial maintenance cost. 
At least it doesn't mandate that I use it.

> A simple way to look at things is - local imports are The Right Thing,
> for many reasons beyond compilation speed. There needs to be a way to do
> the right thing for the declaration part as well.

Function-scoped imports are a good way to hide implementation details 
from people who don't need them.