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

[Andrei Alexandrescu via Digitalmars-d]

On 12/18/16 1:03 PM, Joakim wrote:
> I largely agree with Dmitry. Ilya refactored several Phobos modules to
> use scoped, selective imports much more, and I pitched in for some
> remaining imports in the largest modules, so that only these
> module-level imports remain, ie those necessary for symbols imported in
> template constraints:
>
> std.datetime - https://github.com/dlang/phobos/pull/4373/files
> std.uni - https://github.com/dlang/phobos/pull/4365/files
> std.string and std.traits - https://github.com/dlang/phobos/pull/4370/files

Yah, there's been a lot of good work (Jack Stouffer did a lot as well 
IIRC) on pushing imports inside. The following searches should be relevant:

git grep '^\(private \)\?import' | wc -l

yields about 426 top-level import declarations. The number of indented 
imports is 4605:

git grep '     *import\W' | wc -l

So we're looking at 10% of imports being problematic. Sadly, they turn 
out to make things quite difficult for Phobos. Last time I looked at the 
module dependency graph it wasn't a lot better than it used to before 
scoped imports. (I don't have it handy... could anyone please produce it?)

> When I first saw this DIP, like Dmitry I was happy that we could get rid
> of those too, but the more I see these horrible syntax suggestions for
> what is really a minor convenience, I changed my mind.  std.datetime,
> the 35k line (17 kloc according to Dscanner) beast of phobos, only needs
> 20 or so symbols at module-scope. std.uni- 10k lines, 4.2 kloc- only
> needs 17 symbols, all from the three modules Dmitry mentioned.  I don't
> think his workaround of splitting up modules is even needed for such a
> low amount of module-level imports.

This paragraph is a good example of a couple of counterarguments that I 
think point directly to flaws in the DIP:

(1) The DIP uses Phobos as an example, so it is applicable mostly to 
Phobos. In fact, Phobos is among the systems that would benefit least 
from the DIP: it has only druntime as dependency, and is distributed in 
its entirety. Many projects out there list multiple dependencies and may 
have various building and distribution policies. The converse is to 
believe that working around a problem in Phobos would render the DIP 
less useful in general.

(2) "I don't like the syntax, hence I don't like the feature." I see 
this as a good opportunity for tasteful design, not a downside of the 
feature.

> Maybe there are other issues having to do with symbol resolution and
> dependency encapsulation that are addressed by this DIP, ie the
> technical performance of the compiler rather than refactoring or code
> clarity, that I don't fully grasp, but from the first two points of the
> claimed benefits of DCDs, ie ease of reasoning about dependencies and
> refactoring code, I don't think this feature will come anywhere close to
> carrying its own weight.

Does the refactoring in https://github.com/dlang/phobos/pull/4962 make 
dependencies clearer? Are you e.g. clear on what you need in order to 
use Appender? Would you want to take this (or another) experiment to 
another module and see how it improves its dependency structure?

> As for the third benefit having to do with scalable template libraries,
> I'm not sure I completely understand all the details there, but I wonder
> if those problems aren't an artifact of the way dmd works now rather
> than something that can't be fixed without this DIP.

The DIP now dedicates an entire section to the pluses and minuses of 
lazy imports, and concludes that lazy imports would address scalability 
if carefully used.


Andrei