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

[Andrei Alexandrescu via Digitalmars-d]

On 12/19/2016 01:47 AM, Joakim wrote:
> Why do you care _so_ much about the module dependency graph?  To make
> this question concrete, let's look at an example, the std.array module
> you keep mentioning.
> This is what it looked like before Ilya scoped as
> many imports as he could:
>
> https://github.com/dlang/phobos/commit/3fcf723aa498b96de165361b5abb9d3450fdc069#diff-54cf8402b22024ae667d4048a5126f0e
>
> That was a mess, similar to opaque C/C++ code, 13 modules imported at
> module-scope were whittled down to 4.  You just made those more specific
> in a commit related to this DIP, by listing the actual symbols
> selectively imported from those four modules:
>
> https://github.com/dlang/phobos/commit/e064d5664f92c4b2f0866c08f6d0290ba66825ed#diff-54cf8402b22024ae667d4048a5126f0e
>
>
> If I'm looking at the template constraints for any particular function
> and see a couple symbols I don't recognize, I don't think it's a big
> deal to find the symbols in that list at the top.

It actually is. Some symbols in e.g. std.range are used in constraints, 
some others used in definitions; some in a UFCS manner. Some code runs 
during compilation, with errors gagged (as in __traits(compiles)) or not 
gagged. I don't know of an easy manual method to figure out who's who 
(which makes Vladimir's idea of tooling it with brute force awesome and 
scary at the same time).

At any way, I don't see how I can use this tidbit to improve the DIP. 
Anything I could add to it to make it more compelling?

> In other words, D already allows you to scope most imports.  I don't
> consider the dozen or two remaining symbols from templaint constraints
> and function arguments to provide much overhead.  Rather, I consider the
> weight of this additional syntax, ie the cognitive overhead from having
> to remember and parse more syntax in my head, to be worse than the
> remaining dependency reasoning problem you're trying to solve: the cost
> outweights the benefit.  Perhaps that's subjective and others may disagree.

It is subjective and difficult to convert into action. Online review 
among folks who know next to nothing about each other does have its 
challenges. What happens here is I post a proposal for a problem that I 
believe is important for large D projects. And I get back "eh, that's 
not as important to me." At a traditional work place we'd know a lot 
about one another's strengths, specialization areas, and design 
sensibilities. Here, all I can do is look at your past PRs (that's why I 
emailed you asking for your github handle; I figure it's @joakim-noah). 
This makes it difficult to act on "I don't buy it" feedback.

> Now, there's also the question of purely technical benefits, like
> compilation speed or executable bloat.  I looked at the latter a little
> last summer, after Ilya had cleaned up a lot of the standard library:
>
> http://forum.dlang.org/thread/gmjqfjoemwtvgqrtdsdr@forum.dlang.org
>
> I found that commenting out a single scoped, selective import of
> "std.string: format" in std.utf led to a 5% decrease in executable size
> for "hello world."  This is a problem with how dmd compiles or appends
> these module dependencies and would presumably still be there after this
> DIP, as you would not remove the dependency.

That might be a related but distinct issue. Can you reproduce that 
experiment?

> I think scoped, selective imports have been great at hacking away at the
> module dependency graph, as you lay out.  It is not clear what technical
> costs you see from the remaining few dependencies and if this DIP is the
> best way to remove them.  I think you should explain why you want to
> untangle the remaining dependency graph, and consider if this DIP is
> really doing that much.

I've made a few more passes through the DIP, but throughout I assume a 
couple of things without stressing them too much - dependencies are 
important, and associating dependencies with declarations makes the 
dependency graph as fine and as precise it could get. I don't see a 
reasonable way to make it better or clearer.

Should I add an introductory section on why dependencies are important?


Andrei