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

[Chris Wright via Digitalmars-d]

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.