Require `#[derive(Event)]` on all Events

[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.

[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.

[alice-i-cecile]

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