<div dir="ltr"><span style="font-size:12.8px">what about using `lazy` instead of `with`:</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">`with(import foo)`</span><div style="font-size:12.8px">=><br>`lazy(import foo)`<div><br></div><div>advantages:</div><div>* <span style="font-size:12.8px">avoids confusion regarding usual scoping rules of `with` ;</span></div><div><span style="font-size:12.8px">* conveys that the import is indeed lazy</span></div><div><br></div><div>Furthermore (regardless of which keyword is used), what about allowing `:` </div><div>```</div><div>// case 1</div><div>lazy(import foo)</div><div>void fun(){}</div><div><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px">// case 2</div><div><span style="font-size:12.8px">lazy(import foo) {</span></div><div><span style="font-size:12.8px">  void fun(){}</span></div><div><span style="font-size:12.8px">}</span><br></div><div><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px">// case 3 : <span style="font-size:12.8px">this is new</span></div><div><span style="font-size:12.8px">lazy(import foo): </span><br></div><div><span style="font-size:12.8px">void fun1(){}</span><span style="font-size:12.8px"><br></span></div><div><div style="font-size:12.8px"><span style="font-size:12.8px">void fun2(){}</span><span style="font-size:12.8px"><br></span></div></div><div style="font-size:12.8px"><span style="font-size:12.8px">```</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">advantages:</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">* same behavior as other constructs which don't introduce a scope:</span><br></div><div style="font-size:12.8px"><span style="font-size:12.8px">```</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">// case 1, 2 3 are allowed:</span></div><div style="font-size:12.8px"><span style="font-size:12.8px">version(A):</span><br></div><div style="font-size:12.8px"><span style="font-size:12.8px"><div style="font-size:12.8px">static if(true):</div><div style="font-size:12.8px">private:</div><div style="font-size:12.8px">void fun(){}</div><div>```</div></span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><div style="font-size:12.8px"><span style="font-size:12.8px">* avoids nesting when case 3 is used (compared to when using `{}`)</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div></div><div style="font-size:12.8px"><span style="font-size:12.8px">* I would argue that grouping lazy imports is actually a common case; without case 3, the indentation will increase.</span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 19, 2016 at 8:56 PM, Timothee Cour <span dir="ltr"><<a href="mailto:thelastmammoth@gmail.com" target="_blank">thelastmammoth@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Andrei: you can use blockquotes to make long lines wrap when quoting text:</div><div><br></div><a href="https://github.com/adam-p/markdown-here/wiki/Markdown-Here-Cheatsheet#blockquotes" target="_blank">https://github.com/adam-p/<wbr>markdown-here/wiki/Markdown-<wbr>Here-Cheatsheet#blockquotes</a><br><div><br></div><div>that way, we don't have to scroll everytime there's a quote, eg:</div><div><br>replace:</div><div><tab>Such scaffolding is of course <br>with:</div><div>> Such scaffolding is of course <br><br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 19, 2016 at 8:04 PM, Andrei Alexandrescu via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 12/19/2016 01:47 AM, Joakim wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why do you care _so_ much about the module dependency graph?  To make<br>
this question concrete, let's look at an example, the std.array module<br>
you keep mentioning.<br>
This is what it looked like before Ilya scoped as<br>
many imports as he could:<br>
<br>
<a href="https://github.com/dlang/phobos/commit/3fcf723aa498b96de165361b5abb9d3450fdc069#diff-54cf8402b22024ae667d4048a5126f0e" rel="noreferrer" target="_blank">https://github.com/dlang/phobo<wbr>s/commit/3fcf723aa498b96de1653<wbr>61b5abb9d3450fdc069#diff-54cf8<wbr>402b22024ae667d4048a5126f0e</a><br>
<br>
That was a mess, similar to opaque C/C++ code, 13 modules imported at<br>
module-scope were whittled down to 4.  You just made those more specific<br>
in a commit related to this DIP, by listing the actual symbols<br>
selectively imported from those four modules:<br>
<br>
<a href="https://github.com/dlang/phobos/commit/e064d5664f92c4b2f0866c08f6d0290ba66825ed#diff-54cf8402b22024ae667d4048a5126f0e" rel="noreferrer" target="_blank">https://github.com/dlang/phobo<wbr>s/commit/e064d5664f92c4b2f0866<wbr>c08f6d0290ba66825ed#diff-54cf8<wbr>402b22024ae667d4048a5126f0e</a><br>
<br>
<br>
If I'm looking at the template constraints for any particular function<br>
and see a couple symbols I don't recognize, I don't think it's a big<br>
deal to find the symbols in that list at the top.<br>
</blockquote>
<br></span>
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).<br>
<br>
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?<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In other words, D already allows you to scope most imports.  I don't<br>
consider the dozen or two remaining symbols from templaint constraints<br>
and function arguments to provide much overhead.  Rather, I consider the<br>
weight of this additional syntax, ie the cognitive overhead from having<br>
to remember and parse more syntax in my head, to be worse than the<br>
remaining dependency reasoning problem you're trying to solve: the cost<br>
outweights the benefit.  Perhaps that's subjective and others may disagree.<br>
</blockquote>
<br></span>
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.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now, there's also the question of purely technical benefits, like<br>
compilation speed or executable bloat.  I looked at the latter a little<br>
last summer, after Ilya had cleaned up a lot of the standard library:<br>
<br>
<a href="http://forum.dlang.org/thread/gmjqfjoemwtvgqrtdsdr@forum.dlang.org" rel="noreferrer" target="_blank">http://forum.dlang.org/thread/<wbr>gmjqfjoemwtvgqrtdsdr@forum.dla<wbr>ng.org</a><br>
<br>
I found that commenting out a single scoped, selective import of<br>
"std.string: format" in std.utf led to a 5% decrease in executable size<br>
for "hello world."  This is a problem with how dmd compiles or appends<br>
these module dependencies and would presumably still be there after this<br>
DIP, as you would not remove the dependency.<br>
</blockquote>
<br></span>
That might be a related but distinct issue. Can you reproduce that experiment?<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think scoped, selective imports have been great at hacking away at the<br>
module dependency graph, as you lay out.  It is not clear what technical<br>
costs you see from the remaining few dependencies and if this DIP is the<br>
best way to remove them.  I think you should explain why you want to<br>
untangle the remaining dependency graph, and consider if this DIP is<br>
really doing that much.<br>
</blockquote>
<br></span>
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.<br>
<br>
Should I add an introductory section on why dependencies are important?<br>
<br>
<br>
Andrei<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>