digitalmars.D - Why not run external DLL code at compile time?
- Luke (27/27) Jan 07 2016 Been following Jonathan Blow's language design talks for a while
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. https://www.reddit.com/r/programming/comments/2kxi89/jonathan_blow_a_programming_langua 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