Just looking at this again: > The obvious workaround to the problem that dependencies must be module- > level is to simply define many small modules---in the extreme, one per > declaration.
Andrei works in phobos a lot. Phobos has a lot of large modules. For instance, std.datetime is 35,000 lines. It's not unusual for a phobos module to have over 6,000 lines (std.math, std.typecons, std.traits, std.format, std.conv). I'd normally recommend breaking up modules at one fifth that size. The standard library benefits from low granularity modules. It needs to implement a variety of related tools for working with particular things. For the hunting-for-definitions case, you also need: * a module with more than a few imports, from different libraries or packages * ambiguous names, or functions that are widely used * the user can't use an IDE / ctags / dcd * the user can't use ddox / dpldocs.info, which turns type references into links; or the user is using that and needs to find the definition of a template constraint * the maintainer cannot use selective imports * the maintainer cannot break the module up to reduce the number of dependencies * the maintainer is willing to spend the effort to convert top-level imports into tightly scoped imports For the compilation-speed case, you need: * large dependencies that this allows you to skip (the module combines several types of functionality with different dependencies) * the imported module must be in another compilation unit (incremental compilation or a separate library) * the dependencies can't be used by any other module in the compilation unit * no selective imports * the module being compiled depends on something in the same scope That's a pretty marginal use case.
