On Friday, 12 July 2013 at 23:34:05 UTC, Timothee Cour wrote:
regarding added complexity: the only thing this adds is 1
function (calling
an executable, with option to redirect stdin/out/err). And yes,
that could
read mail as you joked if the user called such a program inside
his D
function, but that would require ZERO change in compiler, apart
from that
ONE function to support calling external programs.
It's one function now. Like CTFE, it won't be long before
everyone is using it and we see its limitations, or we see more
opportunities for further enhancement.
we need this for the same reason we need CTFE: try using
makefiles to
achieve what CTFE does. Using a separate build is way less
convenient and
doesn't allow complex interactions, as it requires the process
to be
sequential: do other stuff THEN compile with dmd. Whereas
integrating it
inside compilation would allow interdependent computations
offloaded to an
external process.
Let's be clear here: we don't "need" this we "want" this.
There's an endless number of features we want, but we have to
draw the line somewhere. This is classic feature creep. As Andrei
said at DConf, we need to be more professional in the development
of D. Endlessly adding features is not a professional approach to
software development.
In my opinion, the only features that should be added at this
point are to fix language problems. For example, some form of
copy constructors will be necessary to fix the const postblit
problem. Adding features for convenience should be postponed for
D3, or at the very least postponed until all major language
issues are resolved.
