<br><br><div class="gmail_quote">On Sun, Jun 23, 2013 at 5:36 PM, Martin Nowak <span dir="ltr"><<a href="mailto:code@dawg.eu" target="_blank">code@dawg.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 06/22/2013 06:45 AM, Timothee Cour wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Example2:<br>
----<br>
auto foo(){return "import std.stdio;";}<br>
mixin(foo);<br>
void fun2(){import b;}<br>
void main(){writeln("ok");}<br>
----<br>
lazy semantic analysis will analyze main, foo but not fun2, which is not<br>
used. foo is analyzed because it is used in a module-level mixin<br>
declaration.<br>
<br>
</blockquote></div>
Overall it's a good idea. There are already some attempts to shift to lazy semantic analysis, mainly to solve any remaining forward reference issues.<br>
Also for non-optimized builds parsing takes a huge part of the compilation time so that would remain, I don't have detailed numbers though.<br>
</blockquote></div><br><div>why 'that would remain' ? in the proposed lazy compilation model, optimization level is irrelevant. The only thing that matters is whether we have to export all symbols or only specified ones. I agree we should require marking those explicitly with 'export' on all platforms, not just windows. But in doing so we must allow to define those exported symbols outside of where they're defined, otherwise it will make code ugly (eg, what if we want to export std.process.kill in a user shared library and std.process.kill isn't marked as export)</div>
<div><br></div><div>Here's a possibility</div><div><br></div><div>module define_exported_symbols;</div><div>import std.process;</div><div><div>export std.process.kill; //export all std.process.kill overloads (just 1 function in this case)</div>
</div><div><div><div><div>export std.process; //export all functions in std.process</div></div></div></div><div><div>export std; //export all functions in std</div></div><div><br></div><div>But I think the best is to keep the current export semantics (but make it work on all platforms not just windows) and provide library code to help with exporting entire modules/packages:</div>
<div><br></div><div>module std.sharedlib; //helper functions for dlls on all platforms</div><div>void export_module(alias module_)(module_ mymodule){</div><div>}</div><div>void export_symbols(R) (R symbols) if(isInputRange!R){//export a range of symbols</div>
<div>}</div><div>/+</div><div>usage:</div><div>export_module(std.process); //exports all functions in std.process</div><div>export_symbols(enumerateFunctions(std.process)); //exports all functions in std.process; allows to be more flexible by exporting only a subset of those</div>
<div>+/</div><div><br></div><div><br></div><div><br></div><div><br></div>