Compile time executable calling?
Peter Alexander
peter.alexander.au at gmail.com
Sat Jul 13 01:55:31 PDT 2013
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.
More information about the Digitalmars-d
mailing list