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