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.