064e5e48b4
# Objective `Entity::PLACEHOLDER` acts as a magic number that will *probably* never really exist, but it certainly could. And, `Entity` has a niche, so the only reason to use `PLACEHOLDER` is as an alternative to `MaybeUninit` that trades safety risks for logic risks. As a result, bevy has generally advised against using `PLACEHOLDER`, but we still use if for a lot internally. This pr starts removing internal uses of it, starting from observers. ## Solution Change all trigger target related types from `Entity` to `Option<Entity>` Small migration guide to come. ## Testing CI ## Future Work This turned a lot of code from ```rust trigger.target() ``` to ```rust trigger.target().unwrap() ``` The extra panic is no worse than before; it's just earlier than panicking after passing the placeholder to something else. But this is kinda annoying. I would like to add a `TriggerMode` or something to `Event` that would restrict what kinds of targets can be used for that event. Many events like `Removed` etc, are always triggered with a target. We can make those have a way to assume Some, etc. But I wanted to save that for a future pr. |
||
|---|---|---|
| .. | ||
| library | ||
| README.md | ||
no_std Examples
This folder contains examples for how to work with no_std targets and Bevy.
Refer to each example individually for details around how it works and what features you may need to enable/disable to allow a particular target to work.
What is no_std?
no_std is a Rust term for software which doesn't rely on the standard library, std.
The typical use for no_std is in embedded software, where the device simply doesn't support the standard library.
For example, a Raspberry Pi Pico has no operating system to support threads or filesystem operations.
For these platforms, Rust has a more fundamental alternative to std, core.
A large portion of Rust's std actually just re-exports items from core, such as iterators, Result, and Option.
In addition, std also re-exports from another crate, alloc.
This crate is similar to core in that it's generally available on all platforms.
Where it differs is that its inclusion requires access to a global allocator.
Currently, Bevy relies heavily on allocation, so we consider alloc to be just as available, since without it, Bevy will not compile.