As a programmer, both answers posted so far are incorrect. While it's possible to come up with a hypothetical situation in which pressing Alt-F4 would corrupt a save in progress, actually doing so would require the developers to quite deliberately go out of their way to screw up the saving system.
From a coding perspective, the user pressing Alt-F4 does not "close the active window", nor does it "interrupt the program." What it does is cause Windows to place a
WM_CLOSE message onto the program's event queue. That's all.
The event queue, as the name indicates, is a queue of events for the program to process; this mostly consists of input from the user. At the heart of the code for essentially every program driven by external input, including games, is what's known as an event loop, which checks for input on the event queue, processes it, then repeats the last two steps in a loop forever until it's time to shut down.
There are two things to keep in mind here. First is that the event loop is a linear thing: you don't process event #2 until you're finished processing event #1. And the second is that a
WM_CLOSE message does not "quit the program". It's a special type of input, nothing more. It tells the program that the user has requested that the program close down the current window. The program is free to respond to this in whatever way its code says to, including ignoring it entirely. (This is a very rude thing to do, but developers occasionally do it.) One of the most common responses is to ask the user "Do you want to save before quitting?" and/or provide a way to cancel the close request.
So what happens if the user presses Alt-F4 while the game is in the middle of saving? Keep in mind the first point: processing is linear. Assuming that the save is taking place in the main thread, (which I'll cover a bit further on,) the code can't even check the event queue to see that it's been sent a
WM_CLOSE message until after saving is complete. Therefore there's nothing to interrupt.
It's always possible to have a computer program doing two things at once. This is known as multithreading, running two or more linear "threads" of code execution at the same time. So someone might ask, "what if it's saving in a different thread while the
WM_CLOSE message comes in and gets processed?" The answer to that question is that any developers who do this, their code is likely to corrupt savefiles left, right and center even without the user requesting a quit at an inopportune moment. This is because saving means writing out to disc a copy of the state of the game at the moment. If you do this without interrupting the game, it's possible that something can change in between when you start to save and when you finish, and then the save file ends up with some data that refers to the old state of the game and some that refers to the new state, which don't make any sense together, and you now have a corrupted save file.
This is actually one of the first things anyone learns about multithreading: never let two threads touch the same data at the same time if one (or both) of them is going to be changing it. Failing to follow this principle creates race conditions where data gets corrupted and things fail in bizarre ways. Any competent developer is going to go out of their way to avoid scenarios in which a race condition would pop up. So one developer checking in code that performs a save on a separate thread would most likely be looked upon with horror by the rest of the dev team!
TL;DR: If your game already performs autosaves without corrupting itself, it's safe to assume that there is no risk of corruption in politely asking the game to shut down, (which is what ALT-F4 does,) even if you do so in the middle of a save. When warning screens tell you not to shut down the game while saving, it refers to turning off the power or other more drastic ways of terminating gameplay.