On Fri, Jul 12, 2013 at 1:42 PM, Tofu Ninja <span dir="ltr"><<a href="mailto:emmons0@purdue.edu" target="_blank">emmons0@purdue.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I had an idea recently, wouldn't it be cool to have the ability to call an executable at compile time and capture its output. Something like the string imports but instead of opening and reading a text file, it run an executable, waits for it to finish, and grabs its output.<br>

<br>
It would get really cool if you could pass this executable some args and then mix in its out put into your own code. It could be used similarly to how CTFE are used but with out the overhead of trying to compile that function and what not and with out the limitations on what it can do.<br>

<br>
I could imagine all sorts of things that would be possible with this that is currently not.<br>
<br>
Not sure if this is something that could be implemented easily, but seems like something that could be done and something that would be really cool.<br>
</blockquote></div><br><div>I would definitely love that, and I don't see why this should be hard.</div><div>It should be enabled by a compiler switch (dmd -enable_exec) for obvious safety reasons though (just as string import requires -J).</div>
<div><br></div><div>This enables or simplifies a number of things:</div><div><br></div><div>* ctfeWriteln becomes trivial (this feature has been asked a while ago)</div><div>* CTFE in situations where current CTFE fails</div>
<div>* do things that would temprarily require malloc</div><div>* easily customize compilation process (user would be able to add logging / profile info without touching the dmd compiler)</div><div>* accessing environment variables during compilation</div>
<div><br></div><div>seems to me all that is needed is optionally redirecting stdin/stdout of a forked process inside dmd compilation, with the exec C function family.</div><div><br></div>