bevyengine / bevyengine/bevy

Application should be returned when Bevy runner terminate

Open
#2,937 5 comments 0 reactions 0 assignees View on GitHub
A-App C-Examples C-Usability
Dominant language
Rust
Stars
48.2k
Forks
4.8k
Avg merge
3d 22h
Merged PRs (30d)
161

Description

## What problem does this solve or what need does it fill?

Bevy can be run in headless mode, where you often want to introspect the state of the world (ressource, query, ...) and assert something for test and debugging. Some usefull data are present in Bevy, like time since startup, the whole world state, ...

When an application is constructed and **App::run()** is called, the application never terminate unless :

- The runner is set to "run once".
- The application emit an event called **AppExit**.
- The user have setup a custom runner with his own rule.

When the application terminate, **App::run()** return nothing and you have no way to introspect the final state because the application is now empty due to **std::mem::replace**.

```rust
// impl App
pub fn run(&mut self) {
#[cfg(feature = "trace")]
let bevy_app_run_span = info_span!("bevy_app");
#[cfg(feature = "trace")]
let _bevy_app_run_guard = bevy_app_run_span.enter();

let mut app = std::mem::replace(self, App::empty());
let runner = std::mem::replace(&mut app.runner, Box::new(run_once));
(runner)(app);
}
```

```rust
// App
pub struct App {
pub world: World,
pub runner: Box, // Desugar into ---> Box ()>
pub schedule: Schedule,
}
```

## What solution would you like?

Since there's a clear owner of the Application (the runner), the runner should be able to return the Application and borrow checker should not complain about that.

We can either :

1) Replace self with the returned application (should be favored in my opinion, since we are mutating the world when we run the application).
2) Return the application and let the empty application like that.

## What alternative(s) have you considered?

Don't return the Application and let the user with an empty application. If user don't have any background with **std::mem::replace**, confusion can happen. The user expect the application to be in final state, they don't expect an empty application.

## Additional context

/

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.