--- Comment #16 from Vladimir Panteleev <thecybersha...@gmail.com> ---
(In reply to Ivan Kazmenko from comment #13)
> erases both my p.exe and my p.obj.
I certainly hope you're not complaining about the overwriting of the .obj file!
The attached patch is unacceptable, because:
1. /tmp might be mounted with noexec
2. /tmp might not exist on some systems (e.g. Android)
3. It creates a file with a predictable name, which is a security problem
4. It creates the file with default permissions - if the program contains
sensitive data, it could be snooped by another user
(In reply to Leandro Lucarella from comment #12)
> What it I have a script called `something` and I have a D
> project that has a `something.d` module that gets compiled to `something.o`,
> and I want to use my `something` script in that project? If my `something.o`
> gets replaced by another `something.o` that has nothing to do with my
> project, the results will be really really ugly and hard to know what really
"Don't do that".
Compilers will generally create object and executable files by replacing
extensions on the main file. This applies to D, Rust, Go, Nim, probably others.
Demanding that D conforms to your hypothetical convoluted project structure is
out of line.
I am going to leave this open because Go does something interesting which we
could copy: if the output file exists but it's a script, it produces the error:
go install command-line-arguments: build output "hello" already exists and is
not an object file
We could implement that in DMD, I guess.