<div dir="ltr"><div>Some more details on my proposa based on UDA:</div><div><br></div><div>// applies to next decl<br></div><div>@deps!({import std.algorithm;})</div><div>void test1(){}</div><div><br></div><div>// applies to a set of decls</div><div>@deps!({import std.stdio;}){</div><div>  void test2(){}</div><div>  void test3(){}</div><div>}</div><div><br></div><div>// applies to all following decls (':')</div><div>@deps!({import std.array;}):</div><div><br></div><div>// can specify other dependencies beyond imports and have arbitrary complex logic:</div><div>@deps!({</div><div>  import std.range;</div><div>  static int[100] data2;</div><div>  version(linux){</div><div>    enum data1=import("foo");//string import</div><div>    pragma(lib, "curl");</div><div>  }</div><div>}):</div><div>void test4(){}</div><div><br></div><div>// Can alias some dependencies:</div><div>alias deps1=deps!({import std.algorithm;});</div><div><br></div><div>@deps1</div><div>void test4(){}</div><div><br></div><div>NOTE: the above code compiles if we add</div><div><div>`struct deps(T...){}`, but that logic would be implemented in the compiler.</div><div><br></div></div><div><div style="font-size:12.8px">Advantages:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">* no new syntax (just new semantics)</div><div style="font-size:12.8px">* no nesting inside {} required, so no additional indentation</div><div style="font-size:12.8px">* allows grouping multiple declarations under a single set of imports</div><div style="font-size:12.8px">* `grep import` will still work unlike many of the existing proposals</div><div style="font-size:12.8px">* can use existing traits to query for such imports (eg getSymbolsByUDA) </div><div style="font-size:12.8px">* allows a more general solution (eg also handles `pragma(lib, "curl");` if we want that as well)</div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">(Note: ignore the `<span style="font-size:12.8px">variant 2` i had described above)</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 15, 2016 at 8:32 AM, 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"><div class="HOEnZb"><div class="h5">On 12/15/2016 11:11 AM, Walter Bright wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/15/2016 6:53 AM, Andrei Alexandrescu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The document does specify the advantages and disadvantages of lazy<br>
imports, as follows:<br>
<br>
===<br>
* Full lazy `import`s. Assume all `import`s are lazy without any<br>
change in the<br>
language. That would allow an idiom by which libraries use fully<br>
qualified names<br>
everywhere, and the `import`s would be effected only when names are<br>
looked up.<br>
This would allow scalability but not the dependency-carrying aspect.<br>
===<br>
</blockquote>
<br>
That would be a massive breaking change.<br>
</blockquote>
<br></div></div>
This may be a misunderstanding. The idiom would be opt-in so existing behavior will be preserved (albeit it won't benefit of the improvements).<span class="HOEnZb"><font color="#888888"><br>
<br>
Andrei<br>
<br>
</font></span></blockquote></div><br></div>