proposal: private module-level import for faster compilation

Chris Wright via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 24 08:33:04 PDT 2016


On Sun, 24 Jul 2016 12:53:50 +0000, Sebastien Alaiwan wrote:
> Speeding up compilation should never be considered as an acceptable
> solution here, as it's not scalable: it just pushes the problem away,
> until your project size increases enough.

In order to get an equivalent speedup by refactoring, I need small 
modules. Probably no more than a handful of functions or one type. I also 
need to ensure that my types are as simple as possible -- free functions 
instead of methods, just so I can put them into different modules.

That's busywork for me and an inconvenience for anyone who needs to 
import anything I wrote.

Look at std.algorithm. Tons of methods, and I imported it just for 
`canFind` and `sort`.

Look at std.datetime. It imports eight or ten different modules, and it 
needs every one of those for something or other. Should we split it into 
a different module for each type, one for formatting, one for parsing, 
one for fetching the current time, etc? Because that's what we would have 
to do to work around the problem in user code.

That would be terribly inconvenient and would just waste everyone's time. 
There is no reason to do it when the compiler could do it for us 
automatically.


More information about the Digitalmars-d mailing list