Should zstd check archive consistency before overwriting files?

[Mitmischer]

Is your feature request related to a problem? Please describe.
I stumbled upon this when reporting #4005.
The scenario is that corrupt archives can naturally emerge from disks that fill up during compression.
zstd will overwrite files (after prompting the user).
If the decompressed file is corrupt, the user will lose the overwritten file and he will not have obtained any data from the corrupt archive. This could result in potential data loss if the user is inattentive.
Note that while the user is to blame for explicitly allowing overwriting, zstd could mitigate this very easily.

Describe the solution you'd like
When overwriting files, zstd should check the archive for integrity first (or decompress to a temporary file and move into the existing file when decompression has succeeded).
Along the same lines, decompressing to a temporary would also be beneficial in the scenario where the disk fills up during compression. Then, we could just savely delete the (worthless) temporary without having harmed any other data.

Describe alternatives you've considered
zstd could offer to save the decompressed file under a different name. That's how some folder synchronizing software deals with conflicts.

Additional context
None.

[gcflymoto]

I don't agree with all these extra mechanics imposed on Zstd. The user can handle all these mechanics for Zstd and the scenarios they want to mitigate. If you need /tmp compressed/decompressed files handle that yourself. If you need to test the compressed file first, handle that yourself. I definitely do not want a third temporary file taking up all that extra disk space during compression/decompression.