for example
for generating sources for other languages (interop)
or for viewing/checking auto generated code

version (CS) pragma("interop.file.cs", ...);
pragma("just.to.check.generated.code.d", ...);

1. I know that exists security issues with it but IDK which one. so explain please.

2. allow writing file only to folder (compiler choice) "g" or "gen" for current source file or for current project.
   disallow any changing folder symbols like '/', '\', "..", and less than ASCII SPACE etc

On Thursday, 6 October 2022 at 09:55:34 UTC, a11e99z wrote:

version (CS) pragma("interop.file.cs", ...);
pragma("just.to.check.generated.code.d", ...);

That is never going to be implemented, has been suggested before that compile-time file writing should be supported.

It's a very controversial topic because there's a huge security risk in allowing third-parties access to your filesystem, especially without executing an application or anything and simply from building source code or it being a dependency of some other package.

The risk is much greater when I/O happens at compile-time because it's very difficult for ex. an AV to pick up on malicious intend when it can't really scan for malicious executable code, as AVs typically aren't scanning source codes.

So while you could argue that someone could create malicious code and compile it with your program and the result would be the same, then the difference in it is that if the malicious code runs at compile-time then your system most likely won't pick up on it and protected, while if the same code ran at runtime then your system will most likely do so.

On Thursday, 6 October 2022 at 12:08:16 UTC, bauss wrote:

We already have read compile-time access to a system by import("foo.txt"). How does write access change the risk in principle?

It's possible to prevent inclusion of generated file into the compilation. For example, generated file might not be in any -I/-J (sub)dirs.

On Thursday, 6 October 2022 at 12:08:16 UTC, bauss wrote:

But we've already basically been there for decades through:

• configure scripts from autotools
• Makefiles
• Ad-hoc shell/Python build scripts
• dub.json/dub.sdl calling out to shell

If you're willing to trust any of these, I don't see why you shouldn't be able to trust code from the program you're building.

D has always been my true language love, but I'm honestly very excited for Jai simply because it has unrestricted compile-time execution that it uses to replace the need for external build scripts (and cases like OP desires). Hope he gets it out of private beta soon because I'd really like to see how the "Write your build script in the same language your program is in" idea pays off. Zig does something similar with its build.zig stuff, but this seems more comprehensive.

On Thursday, 6 October 2022 at 09:55:34 UTC, a11e99z wrote:

are there other languages you would like to be supported?
C/C++ are available with -HC family of switches.

mixin has this option already:
-mixin=<filename> expand and save mixins to file specified by <filename>

On Friday, 7 October 2022 at 21:45:25 UTC, TheGag96 wrote:

Fwiw Nim supports that since about a decade now... It's of course harder to be excited about something that already actually exists and works. ;-)

On Friday, 7 October 2022 at 16:22:22 UTC, Andrey Zherikov wrote:
[...]

Quote: "Note that by default an import expression will not compile unless one or more paths are passed via the -J switch. This tells the compiler where it should look for the files to import. This is a security feature."

Nice try.

On Saturday, 8 October 2022 at 10:48:49 UTC, kdevel wrote:

Writing can be implemented the same way: it works only when a specific command line parameter is provided, or error out otherwise.

Tis is not an answer to the question how does writing make security risks higher comparing to existing reading.

On Saturday, 8 October 2022 at 13:28:54 UTC, Andrey Zherikov wrote:
[...]

What about

   ~/.ssh/authorized_keys?

or

   ~/.profile
   ~/.bashrc

Now assume someone coaxes you to compile his code under your account. See the problem which does not exist if the compiler could only read those files?