www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why not run external DLL code at compile time?

Been following Jonathan Blow's language design talks for a while 
now (he's a game developer working on a gaming-oriented C++ 
replacement language: https://www.youtube.com/watch?v=UTqZNujQOlA 
). A lot of cool ideas that as a C++ developer I'd love to be 
able to use. It got me curious about other more mature languages 
out there in that category - Go, Rust, and especially D - and 
I've started poking around in the forums here and on the internet.

One of the cooler features he demo'd was arbitrary compile-time 
code execution - he had a little OpenGL space invaders game that 
ran during compile, and your score from the game got returned 
from the "invaders" function and compiled into the code.

I had read some responses from Walter Bright (e.g. 
e_for_games/clq6vq7 ) explaining why that might not be such a good idea, and
his decision to limit D's compile-time execution to code that doesn't call out
to any external DLLs (thus preventing installation of viruses, deletion of
files, etc.).

Anyway that's been rolling around in my head a bit, and I'm 
starting to wonder - don't we already have a ton of source code 
(nearly all) whose build process includes shell scripts, batch 
files, pre/post build tasks in IDE's, python scripts etc.? 
Doesn't that pose the same security risks as external DLL calls? 
I'm not an expert on make/cmake/etc. but they certainly also 
allow calling out to executables on the system. So maybe the 
current compilers themselves, gcc / cl / etc. don't leave you 
with that security question in your head, but pretty much nothing 
you build from github etc. these days is pure compiler calls. So 
why not allow external DLLs in D and greatly expand the power of 
its compile-time metaprogramming?

Apologies in advance if I'm missing something obvious, I'm a 
newcomer to D.
Jan 07 2016