[Merged by Bors] - implemented #[bundle(ignore)]

[maccesch]

Objective

Fixes #5559

Replaces #5628

Solution

Because the generated method from_components() creates an instance of Self my implementation requires any field type that is marked to be ignored to implement Default.

---

Changelog

Added the possibility to ignore fields in a bundle with #[bundle(ignore)]. Typically used when PhantomData needs to be added to a Bundle.

[alice-i-cecile]

FYI Github has a built-in "Draft mode" for WIP PRs :)

[maccesch]

@alice-i-cecile Ok all fixed

[maccesch]

@alice-i-cecile I was thinking about this, and I'm not sure about what I'm about to propose 😄

Instead of having a #[bundle(ignore)] should we just ignore PhantomData by default? Making it less redundant...

The downside would be that if you had a custom type called PhantomData you couldn't use it with bundles. But to me that feels like a very small price to pay.

[NathanSWard]

@alice-i-cecile I was thinking about this, and I'm not sure about what I'm about to propose 😄

Instead of having a #[bundle(ignore)] should we just ignore PhantomData by default? Making it less redundant...

The downside would be that if you had a custom type called PhantomData you couldn't use it with bundles. But to me that feels like a very small price to pay.

Don't actually think this is possible, at least at the macro level using the name PhantomData.
Since it's very easy someone could do something like:

type GhostData<T> = PhantomData<T>;

#[derive(Bundle)]
pub struct MyBundle<T> {
  ghost: GhostData<T>,
  // ..
}

And it's also impossible to do it via any sort of type matching e.g.

if TypeId::of<BundleField>() == TypeId::of<PhantomData<?>> {}

Since PhantomData is generic over T where T could be any type.

Granted I'm sure there's probably some hackery you could do with a trait, however, IMO #[bundle(ignore)] is by far the cleanest solution.
Not only that, it's possible there are other use cases to ignore a type inside a bundle. Granted PhantomData is probably like 90% of use cases.

[NathanSWard]

Oh, and one last thing, could we add a test for this?
Basically just have some bundle where we #[bundle(ignore)] one of the fields, and ensure that when we insert the bundle for an entity, the ignored component does not exist for that entity.

[maccesch]

@NathanSWard When making my suggestion I actually had these limitations in mind. I implemented a derive macro for Dioxus where we decided to make all Option<...> types optional by default (just matching by name) because even though you can do all of these shenanigans you demonstrated almost nobody will. So the gain in ergonomics was prioritized over these unlikely edge cases.

Having said that it is true that the aforementioned Option default is something that is used all the time in contrast to this PhantomData case which is probably not used that frequently.

I still think the ergonomics would be worth it. Maybe instead we could have a

#[bundle(include)]
data: PhantomData<...>,

that counteracts the default exclusion for the case that somebody really did name a component "PhantomData" (lol) and leave the #[bundle(ignore)] for those cases where somebody indeed made a type alias for PhantomData.

So in conclusion:

• PhantomData is ignored by default
• can be counteracted by #[bundle(include)]
• you can manually force sth to be excluded by #[bundle(ignore)]

[NathanSWard]

Fwiw, I'm definitely not a big fan of #[bundle(include)].
And forcing people to explicitly use the words PhantomData in their bundle's member feels like more of an anti-pattern and more of a possible future headache then just requiring people to use #[bundle(ignore)].

I'm just generally against any sort of "stringly" typed imementation which is what you seem to be proposing.

[NathanSWard]

This also extends to other marker types, e.g. PhantomPinned. Having a simple #[bundle(ignore)] to account for any marker like type seems like the most generic/simplest solution, instead of just special casing for PhantomData where the implementation has sharp corner cases.

[alice-i-cecile]

This also extends to other marker types, e.g. PhantomPinned. Having a simple #[bundle(ignore)] to account for any marker like type seems like the most generic/simplest solution, instead of just special casing for PhantomData where the implementation has sharp corner cases.

Yep, this is my feeling. I also like how much more explicit the ignore solution is. Deviations from the expected behavior should be called out.

[maccesch]

Ok got it. Thanks for considering 😄

[maccesch]

@NathanSWard test added ✔️

[SpecificProtagonist]

I agree that we should have #[bundle(ignore)], but does it make sense to unsafe impl<T: Sync + Send + 'static> Bundle for PhantomData<T> (as a no-op) so derive(Bundle) just works, similarly how empty tuples implement Bundle?

[alice-i-cecile]

I agree that we should have #[bundle(ignore)], but does it make sense to unsafe impl<T: Sync + Send + 'static> Bundle for PhantomData (as a no-op) so derive(Bundle) just works, similarly how empty tuples implement Bundle?

IMO this is too implicit. It leads to weird behavior where you can e.g. insert a PhantomData<T> and it does nothing silently.

[BoxyUwU]

derive(WorldQuery) and derive(SystemParam) both use #[world_query(ignore)] [system_param(ignore)] instead of trying to be clever about implicitly ignoring PhantomData. Regardless of whether this is a good/bad idea, all 3 derives should be consistent and imo this is definitely not the PR to be implementing Bundle/SystemParam/WorldQuery for PhantomData (or trying to match the struct name in the proc macro).

[alice-i-cecile]

Great macro code, good tests, useful little feature.

bors r+

[bors]

Build failed (retrying...):

• check-compiles

[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)
• build-without-default-features (bevy)
• build-without-default-features (bevy_ecs)
• build-without-default-features (bevy_reflect)
• check-compiles
• check-doc
• check-missing-examples-in-docs
• ci
• markdownlint
• run-examples
• run-examples-on-wasm
• run-examples-on-windows-dx12