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