The trouble is, malicious people can be very clever at evading such protections. We didn't want to get into an arms race with them. I'm old enough to remember ActiveX.

The code being compiled, when run, could do anything. As for build time, nearly all the build systems that people use in languages like C, C++, Java, Node, etc can do nearly anything.

Saying the compiler can't run user code and make system calls while compiling is is like plugging a whole the size of a bus with your pinky. You prevented absolutely nothing. You just make devs jump through hoops (external tools in their build) to do the things they need to do and in doing so force them to add dependencies which expand their surface area of attacks.

Maybe a command-line switch to say which files can execute code at compile time but still, having worked on a lisp system that ran code and made system calls at compile time it was a huge time saver. Example:

    constexpr max_buffer_size = getSizeOfLargestFile("assets/*.gltf");

    enum Modes = enumerateSupportedModes("modes/*.el");

The problem is an IDE will start compiling code as soon as you open it just to look at it.

Jetbrains products have started prompting if you'd like to open a new project in "safe" mode that disables the build tooling until you've had time to evaluate the project.

So at least some IDEs are more cautious about this these days.

That seems true.

However, I think that if an interpreter does the execution, the interpreter can check every "instruction" that is executed. If every instruction is checked, how could that be evaded?

Honest question because I can't see how, and I need to.

The context for this is an interpreter that doesn't allow direct syscalls; only syscalls through the interpreter.

It seems even D has that because dynamic allocation could call `mmap()`, and you mentioned that D allows comptime dynamic allocation. So I'm confused.

Jai allows arbitrary syscalls at compile time, AFAIK.

Yes, the "classic" Jai example from early in development compiles a program which IIRC just prints out your score like "You got 10 points" every time you run it - but during compilation it finds the score by playing a video game, live, so if you want that program to say "You got 100 points" you need to score 100 points during compilation, once you "die" in the game your compilation finishes.

Whether this is desirable is dubious. But fundamentally it's not any more dangerous than Mara's nightly_crimes! Rust proc macro (which during compilation replaces your running compiler with a compiler that believes it is compiling the standard library and thus allows non-stable "nightly" features even though you aren't running a nightly build, then casually alters the compiler output to say that this was fine and there's nothing to worry about), or any number of other tricks which result from being powerful enough at compile time.

I doubt that D is as powerful as people would want and yet manages to ensure this can't happen. There are Rust people thinking about WASM sandboxing for this, but it's tricky.

I believe you. However, I'm not sure how opening up my build system a little more the D would open the floodgates of people evading the sandbox.

> D allows comptime dynamic allocation. So I'm confused.

with the GC, which is safe

They can, but this is a trillion dollar problem (cloud) now so it's harder than you might imagine

I think you meant to reply to me, not Walter Bright.

And yes, this is a trillion dollar problem. I may be just some bloke with an idea, trying to make it happen. However, I have the free time to try, so why not?

I meant to reply to Walter, he isn't a server guy so be probably isn't familiar with how modern systems defend against this problem.