Andrei: you can use blockquotes to make long lines wrap when quoting text: https://github.com/adam-p/markdown-here/wiki/Markdown-Here-Cheatsheet#blockquotes
that way, we don't have to scroll everytime there's a quote, eg: replace: <tab>Such scaffolding is of course with: > Such scaffolding is of course On Mon, Dec 19, 2016 at 8:04 PM, Andrei Alexandrescu via Digitalmars-d < [email protected]> wrote: > 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/3fcf723aa498b96de1653 >> 61b5abb9d3450fdc069#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/e064d5664f92c4b2f0866 >> c08f6d0290ba66825ed#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/[email protected] >> >> 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 >
