[Merged by Bors] - Make most Entity methods const

[djeedai]

Objective

Fixes #5687

Solution

Update the methods on the Entity struct to be const, so we can
define compile-time constants and more generally use them in a const
context.

---

Changelog

Added

• Most Entity methods are now const fn.

[MinerSebas]

In principle, I agree with this change, the more code that can be executed at compile time, the better.

In practice, I don't see a (current) benefit for these fn's to be const already, as Entity is an unstable runtime identifier.
Only once you can run the (whole) ecs at compile-time, do I see any benefits here.

[djeedai]

In principle, I agree with this change, the more code that can be executed at compile time, the better.

In practice, I don't see a (current) benefit for these fn's to be const already, as Entity is an unstable runtime identifier. Only once you can run the (whole) ecs at compile-time, do I see any benefits here.

I want to make an invalid Entity to initialize my batching, like this:

const INVALID: Entity = Entity::from_bits(u64::MAX);

You can argue that this will break when the 4th billionth entity reaches its 4th billionth generation; I'm willing to take that risk as a limitation of my batching algorithm. I'm also willing to bet other stuffs will break before anyone reaches that limit.

So I appreciate defining an invalid Entity is controversial, I didn't include it in this PR, but at least I'd like to be able to do it in my crate.

[bjorn3]

I think a better alternative would be defining an invalid entity (with eg index 0) in bevy as const and making sure that it doesn't get allocated, which I think is possible by "allocating" it with EntityMeta::EMPTY.

[djeedai]

I think a better alternative would be defining an invalid entity (with eg index 0) in bevy as const and making sure that it doesn't get allocated, which I think is possible by "allocating" it with EntityMeta::EMPTY.

This requires the current PR though, doesn't it? 😬

[bjorn3]

No, you can have impl Entity { const INVALID: Entity = Entity { id: 0, generation: 0 } } in bevy_ecs without this PR.

[cart]

I like @bjorn3's suggestion. Letting users define custom const entities feels like a foot gun.

[djeedai]

I like @bjorn3's suggestion. Letting users define custom const entities feels like a foot gun.

Sure, but that's a much larger and more complex change, even maybe due for an RFC if now all systems need to account for this.

We could use ideally some NonZero<u32> so we can benefit from the compiler optimization of Option when we want to store an Entity possibly invalid.

[cart]

I guess in fairness we do already support creating these identifiers from their "pieces" at runtime (which is also generally a foot gun for the same reasons).

Supporting specific entities at compile time isn't particularly different, and I do like the idea of not needing Options or unsafe for scenarios like this, despite there being user-facing risk.

Short term, I'm cool with merging this. But long term, we should consider closing up these apis entirely (while still supporting the scenarios we need to support). I do like the idea of Entity:INVALID. Seems worth exploring, but I do agree thats a big-ish change.

[cart]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-and-install-on-iOS
• build-android
• build (macos-latest)
• build (ubuntu-latest)
• build-wasm
• build (windows-latest)
• check-compiles
• check-doc
• check-missing-examples-in-docs
• ci
• markdownlint
• run-examples
• run-examples-on-wasm
• run-examples-on-windows-dx12