I mean, do those people who download and compile code not then generally... run it...?

Perhaps I'm missing something but the issue here seems to be whether you trust the source, not whether syscalls are made at compile time or run time?

Trusting the compiler, CI/CD pipelines and verifiable builds.

Why not instead alert the programmer that compiling this code would call such-and-such system calls?

That's IMO how all software should work. Apple did something similar, AFIAK, in the latest version of MacOS, and failed - it's obviously something that is extremely hard to retrofit onto existing software. But allowing arbitrary execution for new software, and sensibly limiting it (e.g. "this program cannot access the internet") is, I predict, fairly feasible.

Other languages (such as python) have install-time code execution. When you pip install a library, the library can run arbitrary code and of course has access to anything and everything via the python interpreter. The only thing protecting you is faith in pypi. How is compile-time code execution any different?

> How is compile-time code execution any different?

I don't know the Python ecosystem and so can only speculate. PIP install is not compiling the code, it's an installation program. Installing anything that can be executed is potentially dangerous, but I imagine PIP install only installs from a trusted source.

But I'm not going to restrict D to compile only source code from a trusted source.

> Installing anything that can be executed is potentially dangerous, but I imagine PIP install only installs from a trusted source.

Nope, unfortunately not, anyone can publish anything to pypi as long as the name isn’t taken. Plenty of room for abuse with typo-squatting, etc.

I assume most people run the code they compile on the very machine they compile it on, so how does preventing compile-time system calls help stop malware?

It means that the D compiler itself is not the doorway for the malware.

Cross-compiling is a common practice, too.