[CatThingy]

Objective

Be consistent with Resources and Components and have Event types be more self-documenting.
Although not susceptible to accidentally using a function instead of a value due to Events only being initialized by their type, much of the same reasoning for removing the blanket impl on Resource also applies here.

• Not immediately obvious if a type is intended to be an event
• Prevent invisible conflicts if the same third-party or primitive types are used as events
• Allows for further extensions (e.g. opt-in warning for missed events)

Solution

Remove the blanket impl for the Event trait. Add a derive macro for it.

---

Changelog

• Event is no longer implemented for all applicable types. Add the #[derive(Event)] macro for events.

Migration Guide

• Add the #[derive(Event)] macro for events. Third-party types used as events should be wrapped in a newtype.

[james7132]

Tentatively approving this on the same grounds as #[derive(Resource)]. This should provide solid ground for compile time optimization in the future for events (i.e. garbage collection policy).

Marking this as controversial as this definitely adds friction when integrating with third party crates.

[CatThingy]

Closing as this does not improve the developer experience in isolation.

[nicopap]

I don't agree. Admittedly, it was only once, but this feature would have saved me an hour of debugging when I mistakenly used the wrong type in an EventReader.

[joseph-gio]

@CatThingy can you consider re-opening this? Most people seem to think this PR is a good idea.

[targrub]

Doesn't this need documentation changes? Migration instructions?

[alice-i-cecile]

Doesn't this need documentation changes? Migration instructions?

Documentation changes I actually don't think are needed: the blog post will contain a blurb and the examples will all demonstrate the pattern.

Migration guide is done: it's just adding a derive and newtyping when needed. People are used to this with components and resources already.

[cart]

Looks good to me. Consistent with our other ECS apis / traits and paves the way for static event configuration (which we almost certainly want).

[alice-i-cecile]

@CatThingy can you get this passing CI? Once that's done we'll finally merge this in :)