bevy: Teardown/exit systems

Awesome summary. I would love to see a PR or 4 tackling those docs issues, although there’s clearly fundamental issues with how this is designed.

Here is some further points of input from a discussion on Discord, this afternoon.

1. Nothing about App::run() suggests it may or may not return:

   • it will return in the headless case (or without winit)
   • it won’t in the default winit case
   • it doesn’t return ! (like std::process::exit(), which does, and is thus self-documenting) or even something like Result<!, AnError> in the winit-powered case.
   • its documentation makes no mention of any of the above.

   The user is expected to have “arcane knowledge” – In Safe Rust! – and the compiler cannot help them.

2. There is winit::WinitSettings::return_from_run BUT…

   • You must discover that that exists! Likely, one discovers this via the example: app/return_after_run.rs which I will discuss, further, later.
   • Its own documentation basically tells you not to use it.
   • winit’s documentation tells you not to use it, too.
   • (Aside: I’m guessing that both of those have something to do with work-arounds for Windows SPA STA apartment-model processes and message-loop limitations…)

   That’s a whole lot of nuance for a Bevy user to need to know in order to get expected behaviour from App::run()!

3. The WindowClosed event is very easy to discover in the documentation BUT…

   • It isn’t useful. Any system reading it won’t be run because the schedule won’t be executed once the primary window is down.
   • This is also not mentioned in documentation on WindowClosed
   • Neither is a “proper way” presented. In the window-related examples, I found nothing.

4. The aforementioned app/return_after_run.rs example is probably the next most discoverable resource BUT…

   • It does not contain any relevant comments or mention the recommendation to avoid using winit::WinitSettings::return_from_run.
   • It actively illustrates return_from_run as the solution, which it isn’t if the documentation (and winit’s) are accurate.
   • it would not substitute for WindowClosed because, by that time, the entities are gone from the ECS

Both is my preference, in separate PRs.

Those are some valid points! I had not considered implementing Drop, nor had I considered that Drop would still execute if the app was exited through a window closing, and I have verified that it does indeed work in the code. Perhaps if exit systems are not implemented, a note about that would be a good addition to the documentation for AppExit?

That said, I still have a couple points to defend this Idea: The biggest one is that I find that this might be a contention point between Rust idioms and ECS idioms: To my understanding, the principle idea of ECS is that behavior is not contained in the components, but in the systems. But perhaps Drop might be a special case.

And I’ll admit that saving on exit could be a bad idea, the examples of it that I was thinking of actually probably do it through clever use of other systems. Perhaps a better example would be a multiplayer client sending a “LOGOUT” message to the server? While the server would probably eventually get the idea when the client stopped sending keep-alive messages or other input, it’s possible they would delay, which could even lead to bad things happening to the player while they weren’t connected. It could also prevent the player from logging in on another device until the timeout occurred.

This can still be solved with a Drop trait implementation though, so really the thing that needs to be determined is if “Drop” implementations or exit systems would be more idiomatic for the Bevy engine in particular.

This is a good issue. My opinion is that this should just be another schedule (akin to the new startup schedule), which the default runner evaluates once before exiting.

Oooooh, well that’s good to know!

Well, it’s good to know we have more ways of configuring this for the app developer side, but if you’re trying to vend a plugin for additional game functionality, it’s less than ideal to say " be sure to configure your other plugins this way and add this code after the App.run()." We have options that can do this by having a system listen to AppExit events that runs after exits (Though figuring out scheduling is less than ideal), and we can do it by implementing Drop for our components (Which is idiomatic Rust, and might have issues if you have multiples of those components).

I personally still think the major question is still “Should we add explicit exit systems, or should we update AppExit documentation to point out that implementing Drop might be more rust-idiomatic, or both?” Once we solve that question, it looks like we already have ideas on how to implement it?